shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <lhazlew...@apache.org>
Subject Re: Subject-Session relationship
Date Wed, 15 Jul 2009 04:21:01 GMT
Hi Alphy,

This is highly irregular - the only way this could occur is if the Servlet
Container returned null for the httpServletRequest.getSession() call, which
I'm not sure should ever happen.

Typically after logout, a user is redirected to a home page, login page, or
some other status page stating the user has been logged out.  Do you do do
this kind of thing?  If not, you have to be careful not to use the session
after loggging out the Subject.

That is, ensure that during a thread's execution, you do not do this:

subject.logout();

//some more work, anywhere in the application, but before the response is
finished

subject.getSession();

This is a limitation of the servlet container, and not of Shiro.  Just be
aware of when you might be trying to use the http session after you call
logout.  This is a good reason to redirect immediately after calling
logout() to ensure this won't happen to you in a webapp.

I hope that helps!

Les

On Tue, Jul 14, 2009 at 11:05 PM, javamallu <binnyal@gmail.com> wrote:

>
> Hi Les,
>
> Please find the stack trace.
>
> java.lang.IllegalArgumentException: HttpSession constructor argument cannot
> be null.
>        at org.jsecurity.web.session.WebSession.<init>(WebSession.java:51)
>        at
>
> org.jsecurity.web.session.ServletContainerSessionManager.createSession(ServletContainerSessionManager.java:85)
>        at
>
> org.jsecurity.web.session.ServletContainerSessionManager.createSession(ServletContainerSessionManager.java:81)
>        at
>
> org.jsecurity.session.mgt.AbstractSessionManager.start(AbstractSessionManager.java:63)
>        at
>
> org.jsecurity.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:254)
>        at
>
> org.jsecurity.subject.DelegatingSubject.getSession(DelegatingSubject.java:286)
>        at
>
> org.jsecurity.subject.DelegatingSubject.getSession(DelegatingSubject.java:274)
>        at
>
> org.jsecurity.web.DefaultWebSecurityManager.bind(DefaultWebSecurityManager.java:244)
>        at
>
> org.jsecurity.web.DefaultWebSecurityManager.bind(DefaultWebSecurityManager.java:237)
>        at
>
> org.jsecurity.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:329)
>        at
> org.jsecurity.subject.DelegatingSubject.login(DelegatingSubject.java:239)
>
>
> Thanks,
>
> Alphy
>
> Les Hazlewood-2 wrote:
> >
> > Subject#getSession() should not return null.  Do you have a stack trace
> or
> > test case that can re-create this issue?  If so, please create a Jira
> > issue.
> >
> > On Tue, Jul 14, 2009 at 12:50 AM, javamallu <binnyal@gmail.com> wrote:
> >
> >>
> >> Hi,
> >>
> >>
> >> I am also facing a problem regarding sessions .First time when I login
> to
> >> my
> >> application the Subject.getSession returns a valid session and it is
> >> successfully loggedin.But when I logout and login again in same
> >> browser,the
> >> Subject.getSession returns null.Please help.
> >>
> >> Alphy
> >>
> >> Razvan wrote:
> >> >
> >> > Hi everyone,
> >> >
> >> > I am new to JSecurity, I am using it, I have a scenario to implement,
> I
> >> > have
> >> > some problems with it and I thought you could help :)
> >> >
> >> > scenario :
> >> >
> >> > A website that uses JSecurity to manage user's access to different
> >> parts
> >> > of
> >> > the site. Different parts of the site are subject to different terms
> >> and
> >> > conditions. Also, the download of different products are also subject
> >> > different terms and conditions. These terms and conditions may change
> >> > while
> >> > the users are still logged in ( rememberMe or active connection). What
> >> we
> >> > need is that once the terms and conditions for a particular
> >> product/part
> >> > of
> >> > the site is changing, some users must be kicked before doing any
> action
> >> > and
> >> > forced to re-login to accept the new terms and conditions. Having this
> >> > scenario, we need to access a list of all logged in subjects, check
> >> their
> >> > principals against our particular set of users and kick those who
> >> match.
> >> >
> >> >
> >> > problem :
> >> >
> >> > I've got the JSecurity sources and tried to follow code paths, debug
> >> etc
> >> > etc
> >> > and went to the point where I have all the active sessions.
> >> Unfortunately
> >> > I
> >> > haven't found a way to reach the subject associated with that session
> >> and
> >> > I
> >> > can't get the subject's principals and check them against my separate
> >> > list.
> >> >
> >> >
> >> > questions :
> >> >
> >> > What is the way to reach the subject via a session, in my case ?
> >> > Is there another way/s to get all the logged in subjects ?
> >> > Do you think is a good idea to keep a list of authenticated subjects
> in
> >> my
> >> > Realm implementation ? Does it affect clustering or anything else (
> >> mainly
> >> > distributed stuff ) ?
> >> >
> >> >
> >> > still digging :
> >> >
> >> > If you will point me to some listeners, none of the listeners
> >> > (AuthenticatingListener or SessionListener) does not know about the
> >> > subject
> >> > but only auth token, auth info, and session so I cannot really handle
> >> my
> >> > problem (storing the subject somewhere at login time or session
> >> initiation
> >> > time) only by using listeners and without extending some JSecurity
> >> classes
> >> > like SecurityManager impls which is not necessary a big effort but it
> >> > looks
> >> > like it (not very nice to maintain) for such a basic thing.
> >> >
> >> >
> >> > Kind Regards,
> >> >
> >> > Thanks in advance
> >> >
> >> > Razvan
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://n2.nabble.com/Subject-Session-relationship-tp2303079p3254275.html
> >> Sent from the Shiro User mailing list archive at Nabble.com.
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Subject-Session-relationship-tp2303079p3260763.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Mime
View raw message