_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 <[email protected]> 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.
