Hi Brian, > On 9. Jan 2018, at 20:20, Brian Demers <[email protected]> wrote: > > Sounds like that could work. As for invalidating a single remembered me > session, I don't think you would need to deal with an individual cipher, > simply deleting the user's key from your database would do it (as the next > request would fail to lookup the rememberMe key). >
AbstractRememberMeManager already assumes using a cipher. CookieRememberMeManager inherits this. What do you think: make a new class and inherit from CookieRememberMeManager and override the unneeded stuff or create a new class, implement RememberMeManager and duplicate code from CookieRememberMeManager? > You may also need to heavily depend on caching, as each request might require > a DB lookup (but that is up to you and your usage patterns) true, we already use permission, so every request already hits the database. Compared to everything else that is going for loading a web page this single statement is neglectable. I don’t expect another query for rememberMe to cause much issue. But agreed, this really depends on individual usage patterns. Might work for some, not for everyone. > > Keep us posted! Since we need this feature I can dedicate company time on this matter. Will work on this in my repo and open a pull request once I have something figured out. Might need some help troubleshooting. > -Brian > > > On Tue, Jan 9, 2018 at 10:02 AM, Björn Raupach <[email protected] > <mailto:[email protected]>> wrote: > Hi there, > > has anyone worked on a RememberMeManager that stores the the credentials in > the database? > > As far as I can tell the current CookieRememberMeManager encrypts the > principal and store the encrypted value in a cookie. Identity is restored if > we can decrypt the supplied cookie value from the user agent. > > Would it be possible to offload this to a database? Say the cookie value is > just a nonce. A uuid for example. The RememberMeManager implementation must > then look into the database for the nonce. If there is a matching principal > it returns a successful identity. Otherwise it doesn’t. > > This way we could invalidate remembered sessions for some users and not for > all by means of changing the cipher key. > > Does this make sense? Could this work? > > Any ideas would be appreciated. > > kind regards > Björn >
