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
