Re: WebDelegatingSubject bug or my mistake?

[pouicpouic <gh...@gmail.com>]

Hi,

I think it's more a wrong sneaky usage: there is no current (in the sense of
the current thread) subject yet when your listener is called.

Your SessionListener start method is called when saving subject during the
final stage of its creation by the security manager (you can take a look at
the method createSubject in the DefaultSecurityManager: which will call the
DefaultSubjectDAO.save(subject) -> DefaultSubjectDAO.saveToSession(subject)
-> which will merge subject principals in the session calling
subject.getSession() -> which will start the session and call your
listener).

Thus when your listener is notified, current subject has not been bound to
the current thread (and the subject principals have not even been persisted
within the session yet), as a consequence a call to
SecurityUtils.getSubject() will create a new subject instead of the one
whose session has just started.

And when creating a new subject by SecurityUtils, the default
Subject.Builder is used which implies a DefaultSubjectContext instead of a
WebSubjectContext which when provided to the DefaultWebSubjectFactory
creates a Delegate Subject instead of a Web Delegate subject... that's
probably the story behind why you don't get what you expected at the end.

To properly create a web subject, the dedicated builder must be used (like
what is done on the Shiro web filter): Subject subject = new
WebSubject.Builder(request,response).buildWebSubject();
The bug may be that SecurityUtils.getSubject() should rely on a builder
provided by the security manager instead of using the default one. But even
if this was the case, for web subject there is still the problem of
provisioning the current ServletRequest and ServletResponse to the context
BEFORE creating the subject...

So the question is: what do you want to do with your session listener?
If it is to keep track of the guy who has connected, you can take a look at
the authentication listener feature (but same issue there, you won't
necessarily have access to the current subject, and even if it was bound
previously, you will not have the principals up-to-date according to the
login attempt).



--
View this message in context: http://shiro-developer.582600.n2.nabble.com/WebDelegatingSubject-bug-or-my-mistake-tp7577971p7577976.html
Sent from the Shiro Developer mailing list archive at Nabble.com.

Re: WebDelegatingSubject bug or my mistake?

[Les Hazlewood <lh...@apache.org>]

_great_ answer.  Thanks for contributing!

--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282


On Fri, May 3, 2013 at 8:06 AM, pouicpouic <gh...@gmail.com> wrote:
> Hi,
>
> I think it's more a wrong sneaky usage: there is no current (in the sense of
> the current thread) subject yet when your listener is called.
>
> Your SessionListener start method is called when saving subject during the
> final stage of its creation by the security manager (you can take a look at
> the method createSubject in the DefaultSecurityManager: which will call the
> DefaultSubjectDAO.save(subject) -> DefaultSubjectDAO.saveToSession(subject)
> -> which will merge subject principals in the session calling
> subject.getSession() -> which will start the session and call your
> listener).
>
> Thus when your listener is notified, current subject has not been bound to
> the current thread (and the subject principals have not even been persisted
> within the session yet), as a consequence a call to
> SecurityUtils.getSubject() will create a new subject instead of the one
> whose session has just started.
>
> And when creating a new subject by SecurityUtils, the default
> Subject.Builder is used which implies a DefaultSubjectContext instead of a
> WebSubjectContext which when provided to the DefaultWebSubjectFactory
> creates a Delegate Subject instead of a Web Delegate subject... that's
> probably the story behind why you don't get what you expected at the end.
>
> To properly create a web subject, the dedicated builder must be used (like
> what is done on the Shiro web filter): Subject subject = new
> WebSubject.Builder(request,response).buildWebSubject();
> The bug may be that SecurityUtils.getSubject() should rely on a builder
> provided by the security manager instead of using the default one. But even
> if this was the case, for web subject there is still the problem of
> provisioning the current ServletRequest and ServletResponse to the context
> BEFORE creating the subject...
>
> So the question is: what do you want to do with your session listener?
> If it is to keep track of the guy who has connected, you can take a look at
> the authentication listener feature (but same issue there, you won't
> necessarily have access to the current subject, and even if it was bound
> previously, you will not have the principals up-to-date according to the
> login attempt).
>
>
>
> --
> View this message in context: http://shiro-developer.582600.n2.nabble.com/WebDelegatingSubject-bug-or-my-mistake-tp7577971p7577976.html
> Sent from the Shiro Developer mailing list archive at Nabble.com.