Great info...thanks Les.
Pluggability would definitely be a nice feature in this context and I'll
create a feature request for it...thanks.
So if I choose to use EHCache which, as you know, already has a nice
implementation in Shiro, will these implementation issues go away?
In other words, if I switch to using EHCache for the time being, will I have
to address the issues you've described?
Thank you!
James
----- Original Message -----
From: "Les Hazlewood" <[email protected]>
To: <[email protected]>
Sent: Wednesday, July 20, 2011 11:44 AM
Subject: Re: Question about implenting Cache<K,V>
At the moment, Shiro can use 3 different Cache instances if a
CacheManager is configured:
1. A realm's Authentication Cache - the key is the return value of
realm.getAuthenticationCacheKey(authenticationToken), which defaults
to returning authenticationToken.getPrincipal(). If your end user's
submitted AuthenticationToken principals are strings (e.g. usernames
or email addresses), then the runtime keys will be strings and the
runtime values will be AuthenticationInfo instances. Authentication
Caching is disabled by default. If you will not use authentication
caching, you don't need to worry about this.
2. A realm's Authorization Cache - the key is the return value of
realm.getAuthorizationCacheKey(PrincipalCollection) which defaults to
returning the PrincipalCollection immediately. This is an object, not
a String. You can override the getAuthorizationCacheKey method to
return a String instead - maybe by returning
principalCollection.getPrimaryPrincipal() (if that is indeed a
string). You can override it to return a string however you like.
AuthorizationCaching is enabled by default if a CacheManager is
present.
3. CachingSessionDAO implementation's Session Cache - only used if
using Shiro's native sessions. The key is the session ID (a
Serializable object) and the value is a Session object. At runtime,
all of Shiro's session IDs are Strings by default, so you wouldn't
have to do anything special (some end-users have the session ID be a
long integer, i.e. a data store surrogate primary key, which is why
the type is specified as Serializable and not String).
So if you want to require that all keys are Strings and you want to
use AuthorizationCaching (recommended) you will need to override the
realm's getAuthorizationCacheKey method to return a String. Then
everything should work fine.
Ideally this key resolution mechanism should be a pluggable component
so you don't have to subclass a Realm to customize this behavior -
please open a Jira issue as a feature request and we can see about
adding this if you (or someone else) would find it valuable.
HTH!
Best,
--
Les Hazlewood
CTO, Katasoft | http://www.katasoft.com | 888.391.5282
twitter: http://twitter.com/lhazlewood
katasoft blog: http://www.katasoft.com/blogs/lhazlewood
personal blog: http://leshazlewood.com
