-
Notifications
You must be signed in to change notification settings - Fork 299
Description
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.
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.
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?