Are there any drawbacks of using HttpSession invalidate()??

[piklos]

Hello all, I am using seam 2.0.2 sp1 and jboss 4.2.3. I have a specific requirement in my application to enable users to kill a session of another user that is currently logged in (under certain conditions). Since i found no way to do it in seam regular ways, i started collecting all the HttpSessions in a map, and when a user clicks to kill another person's Session i call invalidate() on the particular HttpSession. I always get the exception with a message Please end the session with the jboss.org.seam.Session.Invalidate(). But everything works fine (at least i didn't found anything unusual). I started thinking a ignoring the exception, or make it log to some other file, or something like that.

Is it safe to invalidate other user session vis HttpSession.invalidate()? What are the drawbacks of using that approach? Is there any alternative to doing this kind of invalidation, given my requirements?

Thanks in advance.

[monkeyden]

Hi Brvno,
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)

[monkeyden]

BTW, here is a good post by Dan, explaining his approach:

How can I invalidate a user's http session?

[piklos]

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.
Example:
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

[monkeyden]

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?

[piklos]

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 :)
Thanks everybody!

PS hope this thread can help sombody.

[daniela.danielacano.gmail.com]

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!