You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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?
The text was updated successfully, but these errors were encountered:
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
@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.
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)
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
issuesatinux/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 originalcreatedAt
date is always used for both the session TTL and theexpires
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 sameH3Event
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 callsgetSession
if no session exists:https://github.com/unjs/h3/blob/087d0639cc12a555a87d56fc0ef3cca1fcf282cf/src/utils/session.ts#L123-L126
Proposed Improvements
1) Prevent
updateSession
from restoring sessionsIndependent of the need to refresh sessions, the fact that a call to
useSession().clear()
can be effectively reversed by a call touseSession().update()
is counter-intuitive and probably a little dangerous, so at minimum theupdateSession
function should use an explicit (new)createSession
function OR thegetSession
function be modified to support adoNotRestoreSession
option.https://github.com/unjs/h3/blob/087d0639cc12a555a87d56fc0ef3cca1fcf282cf/src/utils/session.ts#L44-L107
2) Add a
rotateSession
functionWhile not explicitly necessary if the
updateSession
bug is resolved, the ability to have an obvious and clear function for rebuilding the session using a newcreatedAt
value would be helpful. I would expect it would little more than a wrapper around conjoined calls to theclearSession
andupdateSession
that would accept an optionalSessionUpdate<T>
parameter.Additional information
The text was updated successfully, but these errors were encountered: