The requirement to provide functionality to kick someone from the system seems rather brutish but, clearly, someone has a reason for it. Viewing it from the user session perspective, you may have noticed in the Identity.logout() method a call to Session.instance().invalidate() is made. At first glance, it appears you might be able to very carefully implement a thread-safe application-scoped data structure to hold references to Identity or Session instances, to enable control of them. You might also want restrict the component to a specific role(s). Perhaps there is a more robust approach from the application scopes perspective. The primary drawback of kicking someone from the system would, of course, be that you're kicking someone from the system. :)
As a side note, from the docs I see Gavin has added to Session:
Applications using Seam security should call Identity.logout() instead of calling this component directly.
so it looks like if anything can be used from my suggestion, Identity.logout() is the way to go, and let Seam itself manage the Session instance.
Hope it helps!
(yields the floor to the many others more knowledgeable than he)
Thanks for the quick repsone, however i already tried having the handles to all the identity objects in the application, and i tried calling identity.logout() with the identity object that corresponds to the user i want to log out. But that ws just not good.
Let me explain why.
Identity's logout has one side effect and that is to invalidate the current session (the session that the logout matheod has been called from).
So my requirements cannot be done with it.
User A has his session called A-session and his identity object called A-I, and he wants to kick user B that has a session called B-session and identitiy object B-I.
User A obtains the handle to the identity (B-I) object of user B, BUT when user A calls logout on the identity (B-I), as a side effect he gets HIS session (A-session) and not (B-session) invalidated.
I am not sure if that is a bug or a feature of Seam.
That's why I started using HttpSession in the first place directly because it gets the job done. It kills another persons session (B-session) without touching the session it has been called from (A-session).
Only thing that bothers me is the exception i keep getting, with a message that i should
Use Seam's Session invalidate. I patched that exception with no sweat, but i am just wondering will there be some resource leak, or something like that that i need to be aware of?
Thanks in advance
Ahh right, that does make sense. Identity.logout() doesn't have a local reference to the Session instance. Instead, it uses Session.instance().invalidate(), which comes from the current thread (user A). Did you try holding references to the Session object instead, despite Gavin's comment? Then, on login (user B) you can raise an event to toss the Session into the data structure for user A. I don't see anything in Session that may make that approach offensive. The only thing I wonder about is, how does Seam manage it elsewhere?
Yes, I've tried having references to seam Session objects, but when i do invalidate on them the session that i am invalidating only gets scheduled for invalidation. In practice if you try it you will see that your user that is supposed to be invalidate has at least a click or two more before he gets forced out. I do not know why is this happening, but i couldn't implement the needed feature with it (user that is supposed to be logged out could still do critical stuff, such as saving credit card numbers etc. which was not acceptable by my clients).
But finally we came to a painless solution.
Instead of calling invalidate() on particular httpsession which makes seam throw an exception, we call setMaxInactivePeriod(1), which auto expires session after a second if a user doesn't do anything, and even if he makes an action within 1 second time frame, first time that he gets inactive for more than one second he gets logged out. This why seam handles his session without an exception and everything is dandy.That is acceptable to my clients and so it is to me.
We haven't tried what happens if we set the interval to 0 somebody else can :)
PS hope this thread can help sombody.
Brvno Brvnic wrote on Dec 08, 2010 16:42:
Instead of calling invalidate() on particular httpsession which makes seam throw an exception, we call setMaxInactivePeriod(1), which auto expires session after a second if a user doesn't do anything, and even if he makes an action within 1 second time frame, first time that he gets inactive for more than one second he gets logged out.
I was stuck on the same problem and your approach really helped me. Thank you dude!