BTW, I found that a simpler way to do this is to install your own 
Serializer<PrincipalCollection> to the RememberMeManager. It has the added 
benefit that you can control the serialisation more deeply, as the default 
rememberme -cookie can be pretty big.  We had to do this with Shiro 1.1, as 
sometimes the SetCookie-header grew too large for our load balancer… Don't know 
what the state of Shiro 1.2 is, but I'd assume that it still blindly uses Java 
serialization to the entire PrincipalCollection.

/Janne

On Sep 13, 2013, at 21:41 , Christopher Holt <[email protected]> wrote:

> Les,
> 
> I ended up doing basically what was suggested, but I just used a serial 
> number instead of a UUID associated with each user.  When their account is 
> locked or password changed, then the serial number is bumped.  I extended 
> CookieRememberMeManager and had it add and check the serial number in the 
> remember-me cookie.  If it didn't match on deserialize, I just returned a 
> null PrincipalCollection.
> 
> -Chris
> 
> 
> On Fri, Sep 13, 2013 at 1:34 PM, Les Hazlewood <[email protected]> wrote:
> Hi Chris,
> 
> Richard's suggestions are your best bet at the moment.  However, I'd love to 
> hear how you'd wish this to work - it could be a proper feature request that 
> we can put in Jira.
> 
> Thoughts?
> 
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
> 
> 
> On Thu, Aug 29, 2013 at 12:36 PM, Christopher Holt <[email protected]> 
> wrote:
> Thanks for the followup.  I understand that remembered != authenticated, but 
> for most places in my application, I treat them the same.  Except for certain 
> actions which require real authentication. (i.e. pw change, etc).  That being 
> said, I also need the ability to force a re-authentication administratively, 
> and I'm a little surprised it's not a more common requirement.
> 
> The solution you outline and the one in the thread you link is where I was 
> headed.  I just wanted to make sure there wasn't already some functionality 
> within shiro that I was overlooking.
> 
> Thanks for the help,
> -Chris
> 
> 
> On Thu, Aug 29, 2013 at 10:23 AM, [email protected] <[email protected]> 
> wrote:
> Hi.
> 
> I think I understand your question better now, but I think you may have some
> confusion over how RememberMe works.  By default in Shiro, a remembered user
> is not authenticated, and no auto-login is supported.  So, unless you have
> written code to override that behavior, you probably do not need to worry
> about revoking all outstanding remember me cookies.  The user still has to
> re-authenticate even if they are remembered.  A good discussion of the
> default behavior is in this question:
> http://shiro-user.582556.n2.nabble.com/Rememberme-vs-authentication-td3084550.html
> <http://shiro-user.582556.n2.nabble.com/Rememberme-vs-authentication-td3084550.html>
> 
> That said, Shiro has no way I know of to revoke all outstanding remember me
> cookies for a given user, if you still think you need to do that.  If you
> think about it, this is essentially impossible, since the cookie resides in
> the user's browser, not the server; so unless the user interacts with the
> server via the browser, the server cannot unset a cookie.
> 
> I think you could extend the CookieRememberMeManager class so that it stored
> a key/value pair of a random UUID/username in a database, and set just the
> UUID in the cookie; then you could delete that pair from the database when
> you wanted to invalidate all RememberMe tokens; whenever a new session is
> created, you could then verify that any existing RememberMe token is
> validated by the information in the database.  That level of complexity is
> beyond what most people need.
> 
> I hope that is clearer.
> 
> 
> 
> 
> --
> View this message in context: 
> http://shiro-user.582556.n2.nabble.com/How-to-force-a-remembered-user-to-be-forgotten-tp7579089p7579094.html
> Sent from the Shiro User mailing list archive at Nabble.com.
> 
> 
> 
> -- 
> Chris Holt
> Director of Development
> Healthcare Control Systems
> (877)877-8795 ext 115
> 
> 
> 
> 
> -- 
> Chris Holt
> Director of Development
> Healthcare Control Systems
> (877)877-8795 ext 115

Reply via email to