Hi Matt,
I don't know if solution #1 is a viable option - a realm's
implementation can easily change while its name might stay the same in
configuration, so that's not necessarily a trigger to execute Remember
Me-related logic. Also, I don't think #2 is viable because the
Authenticator interface doesn't 'know' about remember me concerns.
Remember Me is more of an implementation detail/feature of the
particular Authenticator implementation.
But that being said, I see a relatively simple solution that is easily
pluggable:
The AbstractRememberMeManager (and its subclasses by extension) accept
a 'serializer' attribute that you can configure.
Perhaps you can create an UpgradeAwareRememberMeSerializer that
subclasses Shiro's DefaultSerializer. Override the 'deserialize'
method to get the old instance, upgrade it to what your app expects,
and then return that new representation. For example:
@Override
public PrincipalCollection deserialize(byte[] bytes) {
PrincipalCollection pc = super.deserialize(bytes);
if (principalsAreFromAppVersion1(pc) ) {
pc = convertToAppVersion2(pc);
}
return to pc;
}
Then you can plug that in to your shiro.ini config:
upgradeAwareRememberMeSerializer = com.my.UpgradeAwareRememberMeSerializer
securityManager.rememberMeManager.serializer = $upgradeAwareRememberMeSerializer
This isn't a general purpose solution for all Shiro users of course,
but it seems like the most relevant solution for your particular
situation. If you think a general purpose solution should be in
place, please open a Jira feature request - the community might have
to brainstorm a bit to figure out how to do it in a generic way first.
Cheers,
--
Les Hazlewood
Founder, Katasoft, Inc.
Application Security Products & Professional Apache Shiro Support and Training:
http://www.katasoft.com
On Wed, Feb 9, 2011 at 3:05 PM, mbrictson <[email protected]> wrote:
>
> Hello,
>
> I am loving the simplicity and the great code-level documentation that Shiro
> provides. Turning on the "remember me" feature just worked! But now that I
> am switching from a one realm implementation to another I am finding that
> the remember me feature is posing a problem.
>
> From what I can tell, Shiro trusts the remember me cookie as long as it can
> be decrypted and deserialized without error. But what if the realm in my
> application has changed such that those remembered principals are no longer
> valid?
>
> Specifically, my realm started out by using a simple String as the
> principal, but in a new version of my app it has changed to using a complex
> type, MyAppPrincipal. The remembered PrincipalCollection deserialized from
> the cookie doesn't have this -- it has the old String value.
>
> I can't find a simple hook in Shiro that allows the remembered principals to
> be validated. Specifically, if my code is annotated with @RequiresUser, this
> check passes as long as the subject has any non-null principal, even if that
> principal is considered unacceptable by my new realm.
>
> Does that make sense?
>
> Essentially what I'm hoping Shiro could do is:
>
> 1. When deserializing the remembered principal check whether the realm name
> in the remembered principal matches one of the realms currently configured
> in the app. If there is no matching realm, the remembered principal is
> considered invalid and the cookie destroyed.
>
> 2. Perhaps in addition, provide a hook in the Authenticator interface (?)
> where remembered principals can be validated, like: boolean
> isRememberedPrincipalsValid(PrincipalCollection).
>
> What do you think?
>
> Or is there already a simple solution to this that I'm missing? :)
>
> --
> Matt
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/How-to-deal-with-remembered-principals-if-realm-has-since-changed-tp6009937p6009937.html
> Sent from the Shiro User mailing list archive at Nabble.com.
