Invalidating sessions

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Invalidating sessions

Mike K
What is a cleanest way to invalidate a session?
I currently reaching into sessionDAO and deleting it, but I think actually taking over that session and logging out would be preferable.
Any ideas?
Reply | Threaded
Open this post in threaded view
|

Re: Invalidating sessions

jameswhetstone
I'm not sure what the cleanest way to do this, but I did the following:

1) add a method  on my custom realm:
public void invalidateUser(PrincipalCollection principals) {

    this.clearCachedAuthorizationInfo(principals);

}


2)

Whenever I want to invalidate a session, I call:

public static void invalidateUserAuth() {


RealmSecurityManager mgr =
(RealmSecurityManager)SecurityUtils.getSecurityManager();

Collection<Realm> realmCollection = mgr.getRealms();

Iterator<Realm> i = realmCollection.iterator();

//There should be only one realm in this configuration.

if(i.hasNext()) {

MyRealm r = (MyRealm)i.next();

r.invalidateUser(SecurityUtils.getSubject().getPrincipals());

}

}


---James


----- Original Message -----
From: "Mike K" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, January 31, 2012 4:39 PM
Subject: Invalidating sessions


> What is a cleanest way to invalidate a session?
> I currently reaching into sessionDAO and deleting it, but I think actually
> taking over that session and logging out would be preferable.
> Any ideas?
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Invalidating-sessions-tp7241745p7241745.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: Invalidating sessions

jameswhetstone
In reply to this post by Mike K
Actually, now that I've reread your post, I misunderstood your question.
You don't want to invalidate the user's authentication/authorization data,
you jsut want to log the user out.

----- Original Message -----
From: "Mike K" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, January 31, 2012 4:39 PM
Subject: Invalidating sessions


> What is a cleanest way to invalidate a session?
> I currently reaching into sessionDAO and deleting it, but I think actually
> taking over that session and logging out would be preferable.
> Any ideas?
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Invalidating-sessions-tp7241745p7241745.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: Invalidating sessions

Les Hazlewood-2
Best thing to do is always subject.logout().  If a web app,
immediately redirect the user to a new view (notice page or login page
or whatever).

On Tue, Jan 31, 2012 at 4:58 PM, James Whetstone
<[hidden email]> wrote:

> Actually, now that I've reread your post, I misunderstood your question. You
> don't want to invalidate the user's authentication/authorization data, you
> jsut want to log the user out.
>
>
> ----- Original Message ----- From: "Mike K" <[hidden email]>
> To: <[hidden email]>
> Sent: Tuesday, January 31, 2012 4:39 PM
> Subject: Invalidating sessions
>
>
>> What is a cleanest way to invalidate a session?
>> I currently reaching into sessionDAO and deleting it, but I think actually
>> taking over that session and logging out would be preferable.
>> Any ideas?
>>
>> --
>> View this message in context:
>> http://shiro-user.582556.n2.nabble.com/Invalidating-sessions-tp7241745p7241745.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>



--
Les Hazlewood
CTO, Katasoft | http://www.katasoft.com | 888.391.5282
twitter: @lhazlewood | http://twitter.com/lhazlewood
katasoft blog: http://www.katasoft.com/blogs/lhazlewood
personal blog: http://leshazlewood.com
Reply | Threaded
Open this post in threaded view
|

Re: Invalidating sessions

Mike K
Thanks Les,
Is there a way to get a subject for a different user - what I am doing is invalidating a session of a user that is not the current user. Is there a way to rebuild the subject from the session?
Reply | Threaded
Open this post in threaded view
|

Re: Invalidating sessions

lprimak
Take a look at this:
http://code.google.com/p/flowlogix/source/browse/tapestry-services/src/main/java/com/flowlogix/security/WebSecurityFilter.java


On Jan 31, 2012, at 8:47 PM, Mike K <[hidden email]> wrote:

> Thanks Les,
> Is there a way to get a subject for a different user - what I am doing is
> invalidating a session of a user that is not the current user. Is there a
> way to rebuild the subject from the session?
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Invalidating-sessions-tp7241745p7241892.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Invalidating sessions

Les Hazlewood
Administrator
In reply to this post by Mike K
Hi Mike,

Yes, definitely:

Subject subject = new
Subject.Builder(appShiroSecurityManager).session(existingSession).buildSubject();

be aware that this instance is not a web-aware Subject instance.  If
you're doing this work in the context of a ServletRequest/Response,
you might want to use the WebSubject.Builder instead.

Cheers,

Les

On Tue, Jan 31, 2012 at 5:47 PM, Mike K <[hidden email]> wrote:
> Thanks Les,
> Is there a way to get a subject for a different user - what I am doing is
> invalidating a session of a user that is not the current user. Is there a
> way to rebuild the subject from the session?
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Invalidating-sessions-tp7241745p7241892.html
> Sent from the Shiro User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: Invalidating sessions

Les Hazlewood-2
In reply to this post by lprimak
Hi Lenny,

I just saw the linked code - note that the ThreadContext is a Shiro
internal class and its usage semantics may change at any time.  In
Shiro 1.2, the ideal way to acquire the SecurityManager is to look up
the Shiro WebEnvironment from the ServletContext (assuming you've
configured Shiro via a servlet context listener as is now
recommended):

WebEnvironment env = WebUtils.getWebEnvironment(servletContext);
SecurityManager securityManager = env.getSecurityManager();

I don't know if this makes sense in the context of your project's (or
Tapestry's) inner workings, and this might just reflect the fact that
the code doesn't yet assume Shiro 1.2 practices, but I thought I'd
point it out in case it would be helpful.

Cheers,

Les

On Tue, Jan 31, 2012 at 6:30 PM, Lenny Primak <[hidden email]> wrote:

> Take a look at this:
> http://code.google.com/p/flowlogix/source/browse/tapestry-services/src/main/java/com/flowlogix/security/WebSecurityFilter.java
>
>
> On Jan 31, 2012, at 8:47 PM, Mike K <[hidden email]> wrote:
>
>> Thanks Les,
>> Is there a way to get a subject for a different user - what I am doing is
>> invalidating a session of a user that is not the current user. Is there a
>> way to rebuild the subject from the session?
>>
>> --
>> View this message in context: http://shiro-user.582556.n2.nabble.com/Invalidating-sessions-tp7241745p7241892.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: Invalidating sessions

lprimak
Not sure if this make sense for this piece of code,
I do want to depend on as little as possible here configuration wise.
Thanks, Les.

On Feb 1, 2012, at 3:27 PM, Les Hazlewood wrote:

> Hi Lenny,
>
> I just saw the linked code - note that the ThreadContext is a Shiro
> internal class and its usage semantics may change at any time.  In
> Shiro 1.2, the ideal way to acquire the SecurityManager is to look up
> the Shiro WebEnvironment from the ServletContext (assuming you've
> configured Shiro via a servlet context listener as is now
> recommended):
>
> WebEnvironment env = WebUtils.getWebEnvironment(servletContext);
> SecurityManager securityManager = env.getSecurityManager();
>
> I don't know if this makes sense in the context of your project's (or
> Tapestry's) inner workings, and this might just reflect the fact that
> the code doesn't yet assume Shiro 1.2 practices, but I thought I'd
> point it out in case it would be helpful.
>
> Cheers,