Hi Janne, Yep, you're correct - the default behavior is to use Java serialization. Shiro can't know which of your principals are needed to re-construct a Subject at a later date, so it must serialize them all to be safe. Your solution is exactly why the Serializer interface was created: to allow custom plugins for more targeted behavior.
Thanks for sharing! -- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 On Sat, Sep 14, 2013 at 4:00 AM, Janne Jalkanen <[email protected]>wrote: > > 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 > > >
