Hi Tamás, This makes sense to me.
At the moment there are only 2 places where Shiro itself will explicitly use the session: 1. during login, to save the authentication state (this is what SHIRO-266 is expected to address) 2. during 'runAs' operations - to save the identity 'stack' to be able to revert later If a session is created at any other time, it is a result of a Shiro end-user calling subject.getSession() or httpServletRequest.getSession(). So even if we addressed numbers 1 and 2, there is still end-user getSession() calls to worry about. I think a potential solution for that is to have SubjectFactory implementations that return a Subject instance that reacts to getSession() and getSession(true) calls by throwing an exception, indicating that sessions are not allowed at any point during that thread's execution. You'd be able to turn that behavior on and off at runtime of course. Thoughts? -- Les Hazlewood Founder, Katasoft, Inc. Application Security Products & Professional Apache Shiro Support and Training: http://www.katasoft.com
