Thanks again Jonathan. I guess the question is, is this not a common use case? Is my use case and its design flawed? I am asking that because if Shiro does not support it out of the box, they did not think it to be a common use case.
Anyways, I guess it is not so much WHICH realm authenticated you, but the value of JSESSIONID having some context (the url path maybe) and the validation of that value (by the security/session manager) being done based on that context. Even if we have two different filters for the two url paths, there is still only one security and session manager in the entire app. To me that seems the basic problem. Rama -- View this message in context: http://shiro-user.582556.n2.nabble.com/Sessions-from-different-filters-interfering-with-each-other-tp7451046p7481506.html Sent from the Shiro User mailing list archive at Nabble.com.
