-
1. Re: Roles issue
j2ee_junkie Jun 20, 2006 10:36 AM (in response to tzablock)See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=47199 for similar problem.
cgriffith -
2. Re: Roles issue
tzablock Jun 20, 2006 11:06 AM (in response to tzablock)Well that's not the exact point - I don't have to check the user roles at runtime or dynamically. The only thing is that (that's how I suppose it does work) the DatabaseLoginModule assigns the roles at the point when the application is started or at the first login not each time the login is performed...or maybe this is rather a tomcat issue that it caches the roles at the beginning not each time the user logs in. The point is that I would like to customize the LoginModule or tomcat security somehow not to cache the roles. I don't want to reimplement Group class.
-
3. Re: Roles issue
j2ee_junkie Jun 20, 2006 11:25 AM (in response to tzablock)There are two points where roles may be cached...
Tomcat caches the Principal and Roles of a user in the session. Thus, inactivating a session removes that cache.
JBossSX has an authentication cache that exists for the length of time specified by timeout option.
If your web security-domain is configured for the same domain as an ejb component, then invalidating the web session will also flush the authentication cache.
Thus if user has properly been logged out of system, then there should be no reason why an update to the database would not be seen imediately.
If this is not happening please let us know, cgriffith -
4. Re: Roles issue
tzablock Jun 22, 2006 9:33 AM (in response to tzablock)In fact the session is being invalidated and the problem still persists. Considering things you've said I think this is a JBossSX issue. Any ideas on how to flush the databaseloginmodule data?
-
5. Re: Roles issue
j2ee_junkie Jun 22, 2006 11:46 AM (in response to tzablock)I already explained where authentication data cache exists in JBoss/embeded Tomcat and how it gets flushed. If you are seeing differenct results then a)use jmx-console to view/manipulate the authentication cache to see what is going on. b) check/post your security configurations to see that what you have configured matches the behavior.
cgriffith