Rolling session with absolute expiry time

[apitts]

Is it possible to have both rolling sessions as well as an absolute expiry time? So, the session will resave and roll with a maxAge of 15 minutes but expire say 24 hours after first created?

[dougwilson]

That isn't a feature currently, unfortunately. But I don't see why that can't be added if someone wanted to make a pull request to add it 👍

[gabeio]

So the cookies expire after 15 minutes but the database session expires after 24 hours no matter what?

[apitts]

@dougwilson Thanks for letting me know! I did take a look and couldn't find it but it's helpful to know for certain.

@gabeio Yes, exactly. The advantage being that if a cookie is compromised for some reason then access would be limited to say that 24 hour period. As it stands, an attacker could ping the server say every 15 minutes and roll the session. An absolute timeout in OWASP terms: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet.

My understanding is that both an idle and absolute timeout together is best practice.

[mauricedoepke]

I would like to add this feature.
If I am correct we have to save either the expiration or the creation date within the session object to be able to achieve this.
That would mean that a name for this variable needs to be reserved within the session object and can not be used for other purposes by the user.

However, it seems to me like bad practice storing this kind of metadata within the session object and forcing the user to be careful not to accidentally overwrite it with other data.

One naive idea to solve that would be not to store the session object directly, but to wrap it into a parent object(eg: {meta: {absoluteTimeout: 12345}, data: originalSessionObject} ) which would allow us to store this kind of metadata without interfering with the actual session data.

Do you have any suggestions on that?

[justinwatkinsact]

I just submitted a PR with code changes, unit tests and readme updates for this issue. If it passes your tests, can you please merge it in?

[justinwatkinsact]

All tests now pass and the code coverage is right.

[jfbelisle]

Any update on this PR ? It's exactly the feature we want to integrate in our session. Which is also an OWASP recommandation.

[jdheywood]

Any news on accepting this?

[dougwilson]

I can take a look. What PR are you folks looking to get accepted (this is just an issue)?

[jfbelisle]

This is the issue, #595

Thanks for taking the time

[dougwilson]

I apologize I did not have an opportunity to review it over the weekend, but will early this week. I set aside some time.

[jfstephe]

@dougwilson - I too have the same issue. This would be great to get in! Any update?
@justinjdickow - Minor comment on PR - specifying the time in seconds rather than milliseconds is inconsistent with MaxAge (happy to have the change without this ATM thought!)