Skip to content

Reduce session TTL immutability or stickiness #1004

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
1 task done
nerdoza opened this issue Apr 1, 2025 · 3 comments · May be fixed by #1010
Open
1 task done

Reduce session TTL immutability or stickiness #1004

nerdoza opened this issue Apr 1, 2025 · 3 comments · May be fixed by #1010
Labels
enhancement New feature or request

Comments

@nerdoza
Copy link

nerdoza commented Apr 1, 2025

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?
@nerdoza nerdoza added the enhancement New feature or request label Apr 1, 2025
@sandros94
Copy link

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
Copy link
Author

nerdoza commented Apr 2, 2025

@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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants