Reduce session TTL immutability or stickiness

[nerdoza]

Describe the feature

Background

A common source of frustration with the nuxt-auth-utils library is the inability to refresh session cookies. The data within the cookie can be mutated and updated, but the expiration time can't be updated once the session is created.

nuxt-auth-utils issues

atinux/nuxt-auth-utils#356
atinux/nuxt-auth-utils#294
atinux/nuxt-auth-utils#314

The fundamental issue appears to be that the session createdAt date introduced in #325 is set at session creation and there is no way to update this date again. Mutations on the session data can be made, but the original createdAt date is always used for both the session TTL and the expires date.

https://github.com/unjs/h3/blob/087d0639cc12a555a87d56fc0ef3cca1fcf282cf/src/utils/session.ts#L139-L146

Having a session with an immutable TTL isn't a huge issue in isolation because in theory you can simply create a new session with a more recent createdAt. That's where the stickiness issue comes into play.

While you can clear the session, an attempt to create a new session in the same H3Event call will result in getting back the same session (new ref, same data) because it always tries to restore a session's event before it creates a new session.

updateSession function calls getSession if no session exists:
https://github.com/unjs/h3/blob/087d0639cc12a555a87d56fc0ef3cca1fcf282cf/src/utils/session.ts#L123-L126

Proposed Improvements

1) Prevent updateSession from restoring sessions

Independent of the need to refresh sessions, the fact that a call to useSession().clear() can be effectively reversed by a call to useSession().update() is counter-intuitive and probably a little dangerous, so at minimum the updateSession function should use an explicit (new) createSession function OR the getSession function be modified to support a doNotRestoreSession option.

https://github.com/unjs/h3/blob/087d0639cc12a555a87d56fc0ef3cca1fcf282cf/src/utils/session.ts#L44-L107

2) Add a rotateSession function

While not explicitly necessary if the updateSession bug is resolved, the ability to have an obvious and clear function for rebuilding the session using a new createdAt value would be helpful. I would expect it would little more than a wrapper around conjoined calls to the clearSession and updateSession that would accept an optional SessionUpdate<T> parameter.

Additional information

• Would you be willing to help implement this feature?

[sandros94]

I'm also interested in this one as I started working on #997

One of the reason I started working with this JWE implementation was because I wanted to have a standard tool that integrated datetime tracking (creation, expiry, updates) on a data level instead of function level.

This, alongside other JWA specs about headers should both allow for project-specific customization and cross-language/platform compatibility.

The more I look at the current implementation and the more I consider this issue being mostly just dirty cache within the event.context

[nerdoza]

@sandros94, I agree that the use of the event.context.session as a sort of cache for session state is a bit of a concern. This entire utility class is structured around this cascading source of truth logic that is implemented within each function. The solution I have submitted in #1010 only addresses one of the gaps within the function calls. There is definitely room for further improvement.

[sandros94]

I agree that the use of the event.context.session as a sort of cache for session state is a bit of a concern.

The main reason, if I understand it correctly, is because this way h3 does not need to re-decrypt the session on each re-use of the same event withing the same request (like for example having multiple middlewares before the actual event handler that provides a response)

I'm going to take a look at your PR