I suspect that this is related to your casting error in the jsp tag as well. Basically, when you implement CacheFactory, it is important that each Cache returned from there be distinguishable. So, the realm will create one cache, and the session dao another. Your implementation needs to be able to return the authorization info to the realm (when passed a PrincipalCollection) and the session to the session dao when passed a session key.
On Tue, Mar 19, 2013 at 2:21 PM, NabbleSometimesSucks < [email protected]> wrote: > So, I am looking at the code, stepping through and our Cache implementation > would store the data based on the sessionID. However, I have found in a > couple of scenarios where the remove method is being passed in the the > PrincipalCollection and not the Session key. > > This looks like from the AuthorizingRealm class abstract class. > > I think this causes a problem for us and why I might have seen so many > sessions keys entered in our cache for just one user logging in once. This > also might be the reason why we sometimes get the null SessionID exception > I > have posted about before. > > Basically our implementation of our Cache stores the data in Redis where > the > key is the SessionID only. > > Thanks for any insight or help to find out how we can get the sessionID > sent > in only. > > Mark > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Why-does-that-cache-get-called-with-different-keys-for-a-single-user-tp7578465.html > Sent from the Shiro User mailing list archive at Nabble.com. >
