Hi there, You don't want to mess with the ThreadContext - that's really there for Shiro's needs only.
As for authentication state, that and the Subject's principals are by default stored in the Subject's session instance under special Shiro attribute keys. You can trace the code starting with the org.apache.shiro.mgt.DefaultSecurityManager#login method implementation. The binding of this data occurs in the #bind method implementation, calling session.setAttribute. This session instance invoked in #bind is really a proxy back to the SecurityManager - not the 'real' EIS-tier Session instance. So the session.setAttribute call from within 'bind' really makes its way down to the AbstractNativeSessionManager#setAttribute method implementation. This implementation basically amounts to this: Session s = lookupRequiredSession(sessionKey); s.setAttribute(attributeKey, value); onChange(s); The first line acquires the EIS-tier Session instance from the SessionDAO#readSession method. The onChange method eventually calls the SessionDAO#update method. I'd definitely connect a debugger - it will allow you to see exactly how the calls work and how they interact with the SessionDAO. HTH, Les On Wed, Jun 16, 2010 at 2:00 PM, enabler <[email protected]> wrote: > > .. following up. I also tried to do: > > ThreadContext.bind(SecurityUtils.getSubject()); > > in my Controller at the time of login but that seems to have no effect (at > least in my case). Same error (subject authenticated = false). > > Given the user is authenticated > (SecurityUtils.getSubject().isAuthenticated() = true) and a row is created > in DB for that user with fields say username, sessionid, blob session. > Where is Shiro looking for (retrieving information from) > SecurityUtils.getSubject().isAuthenticated() during subsequent > readSession/update calls? Is it the database? If so which field in the DB or > is it the ThreadContext/sessionid information? > > Please let me know how I can make my thread/session/subject persistent for > shiro readSession/update calls (when this information is already stored in > the RDBMS). > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Unable-to-implement-create-read-update-session-tp5183219p5188196.html > Sent from the Shiro User mailing list archive at Nabble.com. >
