I'm using a JDBC realm for authentication and authorization. When I remove a role from a user in the DB, the changes are not reflected immediately in the application, only at the next user login. Is it possible that role changes take effect immediately? I know I have to put this logic in the application itself, but I don't know how to apply this changes to a specific user while he's logged in. I'm using GF 3.1.
Asked
Active
Viewed 580 times
1 Answers
1
There are no API-provided ways for this. Your best bet is to wrap the logged-in user (the UserPrincipal
) in your own User
model object (can be as good a (JPA) entity of the very same table) which allows changing the role and then collect all logged-in users in some static/application-wide set/map with help of a Filter
and HttpSessionListener
. Finally, in the admin panel, just check if the User
is there in the set/map then get and alter it accordingly. It'll be reflected immediately for the actual enduser.
Related questions
-
Thanks. How do I alter the UserPrincipal so that it reflects the role changes? The `Principal` class only defines a `getName()` method. Where is the part where I can set the new roles? – Theo Jan 23 '11 at 15:21
-
You can't alter it. That's exactly why I proposed to wrap it in your own model object. You just alter the wrapped model object and use it instead throughout your webapp. If you really don't want to change it, then your best bet is to collect sessions of logged-in users and invalidate it. That's only less friendly UX for the enduser. For some hints about how to collect sessions, check [this answer](http://stackoverflow.com/questions/2372311/jsf-how-to-invalidate-an-user-session-when-he-logs-twice-with-the-same-credentia/2372990#2372990). – BalusC Jan 23 '11 at 15:22
-
OK, you're saying I should use the wrapped user model, which contains the user roles, and perform role checks against the wrapped model. Problem is, I'm also using the Java EE security annotations auch as @RolesAllowed("Rolename") in my EJBs and the p:ifGranted tag from PrimeFaces. Those checks would still use the possibly out-dated roles. So I guess I need to invalidate the sessions... – Theo Jan 23 '11 at 20:19
-
Ah yes, didn't forsee those issues. Right, your best bet is to collect the sessions by user and invalidate them whenever necessary. – BalusC Jan 23 '11 at 20:21