You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by NabbleSometimesSucks <bi...@yahoo.com> on 2013/03/19 20:21:52 UTC

Why does that cache get called with different keys for a single user

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.

Re: Why does that cache get called with different keys for a single user

Posted by NabbleSometimesSucks <bi...@yahoo.com>.
We aren't implementing CacheFactory, just CacheManager and Cache.

So you are also saying that there could be two cache's one for the User
information and one for the Session?

Actually at this point, I normally see just one entry in Redis for a user.
Every once in a while I see three for one user logged in, but that might
happen cause of some other weird issue that we have because we will have at
least 6 different applications logging in and we are trying to implement a
simple only once login with userName password, other website apps would be
automatically logged in. For the other apps that are mobile and using
Sockets, we will use REST to our central Auth-server where they can login
with username password first, then get a token to pass when the socket is
connected.

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-tp7578465p7578495.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Why does that cache get called with different keys for a single user

Posted by Jared Bunting <ja...@peachjean.com>.
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 <
bigtrashcaninthesky@yahoo.com> 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.
>