shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Björn Raupach <>
Subject Re: RememberMeManager in Database
Date Wed, 10 Jan 2018 08:26:41 GMT
Hi Brian,

> On 9. Jan 2018, at 20:20, Brian Demers <> 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

> 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 < <>>
> 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

View raw message