On Tue, May 17, 2011 at 12:58 PM, juminoz <[email protected]> wrote: > I'm currently not explicitly storing Subject anywhere since I thought the > framework automatically handles both subject and session. I basically > assumed that subject stays around until session expires (may never expire).
The notion of a Subject (i.e. 'user') and its session function as you expect them to. I was talking about Shiro's implementation details, which are only relevant if you _don't_ use SecurityUtils.getSubject() in your code (for example, if you call SecurityUtils.getSubject() and then save the returned instance as a class attribute in a long-lived object - this would cause indeterminate behavior). If you call SecurityUtils.getSubject() (or use something that calls that on your behalf) whenever you need to interact with a Subject instance, you're ok. I apologize if I confused anyone! > Now I'm actually a little confused about how's it supposed to work. Brian > mentioned in other thread that I should just keep sessions open and never > actually log out so that authorization info stays in the cache. > > http://shiro-user.582556.n2.nabble.com/Authorization-Cache-Removed-when-Logged-Out-td6360724.html > > If subject is supposed to be short-lived, Brian's suggested approach is not > recommended then? Brian's suggestion is perfectly sound. But it is sound because the cache infrastructure doesn't cache Subject instances themselves - it works because the underlying data that eventually makes up a Subject - the AuthenticationInfo, AuthorizationInfo, and Session instances - are what is cached. > My use cases is as follow: > > Note: Client can be web or non-web. Web client may also invoke non-web > client to invoke non-web service. > > 1) > - Client login with at connection time > - Client logout when disconnect > > 2) > - Client login with when impersonate a user invoking client to call service > (username: <app user>/<end user>) > - Client logout after completion of impersonated call > > Subject in the second use case is short-lived, but long-lived otherwise. My > goal is to cache both authentication and authorization info in the cache so > that in high-volume transactions scenario, the bottleneck on ACL is > minimized. Yep, this won't be a problem. The key to making this work however is that for non-web clients, something needs to set up the Subject instance before the thread executes and something needs to clean up the thread after it is complete (or fails). In a web environment, the root Shiro Filter does this setup/teardown logic per web request automatically. If not in a web environment, you (or likely some framework) must do this instead. You can see an example of this working in a non-web request scenario by viewing Shiro's Spring Remoting support: https://svn.apache.org/repos/asf/shiro/trunk/support/spring/src/main/java/org/apache/shiro/spring/remoting/SecureRemoteInvocationExecutor.java (see the subject.execute call). This is also explained in detail in Shiro's Subject documentation: http://shiro.apache.org/subject.html Specifically, the Subject.Builder and 'Thread Association' sections. Does this help? Cheers, Les -- Les Hazlewood Founder, Katasoft, Inc. Application Security Products & Professional Apache Shiro Support and Training: http://www.katasoft.com
