Wait, so the session doesn't ever actually expire?

[kyle valade]

I could just be reading the docs wrong, and I haven't actually dug into any of the code yet, but I noticed this disclaimer on ScalaSessionFlash.

You can also set the maximum age of the session cookie by configuring the key play.http.session.maxAge (in milliseconds) in application.conf, but note that this does not prevent an attacker from keeping and reusing the cookie past the expiration date.

 Does this mean that a session effectively remains active past its maxAge, or just that a session can be used, but the user will be unauthenticated?

[kyle valade]

Or is there an assumption that the attacker is using the session before it expires and therefore extending its expiry date?

[Thibault Meyer]

It will  just set a TTL to the cookie. so in fact, with browser extension, stay connected ad aeternam even if you set maxAge. To control it server-side, you have to add, by exemple, a timestamp in the cookie and check it at each requests

[kyle valade]

Oh, okay. I keep forgetting how slim of a framework Play is. That seems like something that pretty much everyone would want - is there a reason that functionality isn't built into the framework?

[Christian Schmitt]

it needs a backing store. and play isn't so opinionated to attache a specific one. it's also possible to store the cookie id in the cache and check that.

it's not really hard to implement your self and I guess since so many users do it differently it's practically hard to have a design that would make everybody happy.

[Will Sargent]

You don't even need a backing store -- if you set up the CookieBaker trait as signed, then you can add a timestamp in, and then check it in a filter.  I think it never rose up to the level of an actual problem -- if there's a good way to package it as code, a PR is welcome...

[kyle valade]

Cool, thanks a lot for the responses, Christian and Will! I'll take a look at that later this week and see if I can come up with a PR.

[Thibault Meyer]

it could be nice but keep it in mind that kind of feature must stay optionnal (some user dont want this and using timestamp or other kind of date use more space and the cookie is bigger)

[kyle valade]

I'll definitely keep that in mind - wouldn't want to break backwards compatibility or anything. Thanks Thibault!

[kyle valade]

Thinking more about it, I might go the route of doing a backing store through the Cache. The reason being that if a user logs out, they should expect that their session ID won't work anymore. However, if the expiry timestamp is set in the future, then their session could still be used until that time. Which, while better than being usable forever, still seems bad.

Not sure if that implementation is still something you'd want a PR on, but I know I would have appreciated it, as the existing out-of-the-box session management is somewhat of a security hole.