-
Notifications
You must be signed in to change notification settings - Fork 51
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
feat: remove session id from session data #101
feat: remove session id from session data #101
Conversation
const restoredCookie = new Cookie(cookieOpts) | ||
restoredCookie.expires = new Date(prevSession.cookie.expires) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't check cookie
before calling restore
(
Line 66 in 76459c2
if (session && session.expires && session.expires <= Date.now()) { |
expires
. So this could be a TypeError
, depending on what's in the store
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what should be done about this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
either works I think, but I think it's weird to look at the expiry of the cookie and not the expiry itself.
That said, express-session
only looks at the cookie data, and have not hoisted expires
up into its own top level thing. So we could do the same here and just get rid of the top level expires
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Go for that!
request.sessionStore.set('aYb4uTIhdBXCfk_ylik4QN6-u26K0u0e', { | ||
expires: Date.now() + 1000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this test, so this change is probably wrong
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what would you like to do about this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to dig into the test to understand what it's supposed to test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the intent of this test was to verify that the old secret still works. The expiration should be + 1000 to make sure the cookie hasn't expired yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did some spelunkling. Why did this test pass earlier?
- The session was modified
sessionId
andencryptedSessionId
were NOT in the session store- This meant that a new session was created to contain the modifications
Thanks to your changes, sessionid / encryptedSessionId don't have to be in the test prep. This means the existing session will be used!
request.sessionStore.set('Qk_XT2K7-clT-x1tVvoY6tIQ83iP72KN', { | ||
expires: Date.now() + 1000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this test is explicitly "if expired", not sure why expiry was set in the future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, this test only passed because of request.session.test = {}
in the handler modified the session.
I'm starting forking off your branch, rebasing and removing...
bd44a82
to
a371c36
Compare
a371c36
to
bd4706f
Compare
@SimenB Hey! Can I help somehow to finish this PR? I'd need this change as well 🙏 |
@sarneeh sure, go for it! We tried rolling this out at work, and had to revert due to some sessions seemingly not updating correctly. Unfortunately I haven't found the time yet to dig into it, which also means this PR is on the backburner for the moment (and now I'm on vacation, so won't get to it for at least a few more weeks). However, feel free to pick this up in the meantime! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rebased + fixed some issues in: #114
request.sessionStore.set('Qk_XT2K7-clT-x1tVvoY6tIQ83iP72KN', { | ||
expires: Date.now() + 1000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, this test only passed because of request.session.test = {}
in the handler modified the session.
I'm starting forking off your branch, rebasing and removing...
request.sessionStore.set('aYb4uTIhdBXCfk_ylik4QN6-u26K0u0e', { | ||
expires: Date.now() + 1000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the intent of this test was to verify that the old secret still works. The expiration should be + 1000 to make sure the cookie hasn't expired yet.
request.sessionStore.set('aYb4uTIhdBXCfk_ylik4QN6-u26K0u0e', { | ||
expires: Date.now() + 1000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did some spelunkling. Why did this test pass earlier?
- The session was modified
sessionId
andencryptedSessionId
were NOT in the session store- This meant that a new session was created to contain the modifications
Thanks to your changes, sessionid / encryptedSessionId don't have to be in the test prep. This means the existing session will be used!
[hash] () { | ||
const sess = this | ||
const str = stringify(sess, function (key, val) { | ||
// ignore sess.cookie property | ||
if (this === sess && key === 'cookie') { | ||
return | ||
// we want `touch` to affect the hash of the session | ||
return sess.cookie.expires |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be sess.cookie.expires.toISOString()
or something. The Date
object gets transformed into {}
by stringify
e.g. str becomes something like {"cookie":{},"csrfSecret":"5iGefd13a29MxLBIMvAT5hrZ","passport":{"user":7}}
closing this in favor of #114 |
Checklist
npm run test
andnpm run benchmark
and the Code of conduct
Fixes #52
Closes #70
I'm not 100% sure about the test changes, would like a second pair of eyes