Hi Les, Thanks for the pointer.
Does manually creating a subject also create a put a session in the cache? The reasons I wanted the thread unbound right after login are as follow: 1) Request to login does nothing more than just a login. If the session/subject can be cache by manually creating the subject, I think that may work out better as you suggested. Basically, the logic for the client application would then be "if there is no session ID, send username/password with the request". This will eliminate request to login completely. The username/password may then contain 2 usernames and 2 passwords, 1 for app user and 1 for end user (when end user is actually relevant). Subject will then represent the combination. Otherwise, just username/password. All permissions are AND'ed in the framework (app user permission, end user permission, group/subgroup permissions). 2) Subject.login() binds subject to the current thread and even after execution, it doesn't automatically unbind. If this is the only way to create a session, I will probably still want to unbind the thread manually after logging in. The goal is to use session ID for all subsequent requests as long as the session is still alive. I will trace through how Shiro works internally to find out more. Thanks, Jack -- View this message in context: http://shiro-user.582556.n2.nabble.com/Checking-Session-Timeout-tp6373753p6382670.html Sent from the Shiro User mailing list archive at Nabble.com.
