Actually I was looking at the implementation of ThreadContext#getSubject today (which is what SecurityUtils#getSubject calls).
It seems that ultimately getting the right subject is hinged on having a separate thread for each executing user. Which also begs another question: Even setting NIO aside, how does Shiro find the right subject in the course of a long user interaction with a web application? E.g. user logins on view A.xhtml and then clicks on view B.xhtml and continues navigating inside the application. Is there any guarantee that the web container will use the same Thread for all subsequent requests ? Otherwise how is Shiro able to consistently return the same subject in the course of a user's interaction with the application ? As regards to your proposed approach of building the Subjects yourself via sessionId, I suppose like this: Subject subject = (new Subject.Builder()).sessionId(sessionId).buildSubject(); >From what I understand, the above is only possible when using Shiro native sessions (not container-managed). KR, Menelaos. On Mon, Nov 26, 2012 at 10:11 PM, David Idol <[email protected]> wrote: > I would like to use Shiro with an asynchronous, NIO-based server (JBoss > Netty). Because this server is based on NIO, it does not use the single > thread per request model (one selecting thread can be used to service > multiple requests, or "Channels" in Netty terms). As such, we cannot assume > that any thread is servicing only a single client. > > I would like to associate a Shiro "Subject" with each Netty "Channel"; > does anyone have any advice on how to do this successfully? The best thing > I have been able to come up with (although I have not tested it) is > building Subject instances manually whenever a new Channel is initiated and > then looking up the Subject in whatever thread is executing via the > sessionId (which gets sent initially to the client and then received by the > server with every request). > > The application is not a web application (uses persistent socket > connections instead of HTTP) if that matters. > > Thanks, > David >
