-
-
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
Remove session id and encrypted session id from session data #114
Remove session id and encrypted session id from session data #114
Conversation
This meant that the test passed even though the session was not actually expired
- Need saveUnitialized: false and https for this condition to happen. - Problem was that we need to hash dates correctly. - Test revealed other problem: dates were not actually Date objects many times. Made all tests use a Date object for expires or removed expires entirely if the test did not need it
c123ed6
to
96c180c
Compare
@@ -62,13 +62,14 @@ function decryptSession (sessionId, options, request, done) { | |||
newSession(secret, request, cookieOpts, idGenerator, done) | |||
return | |||
} | |||
if (session?.expires && session.expires <= Date.now()) { | |||
if (session?.cookie?.expires && session.cookie.expires <= new Date()) { | |||
const restoredSession = Session.restore( |
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 should re-evaluate:
- Whether or not to use object params. Once we get to like 8 it gets pretty confusing
- Whether Session.restore should exist at all. At this point, it's mostly a wrapper around prevSession
this[originalHash] = this[hash]() | ||
this.touch() // Needs to happen after originalHash is set, in case maxAge forces an update |
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 was a bug in the original PR. Added a test against it
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.
nice!
@@ -309,7 +290,7 @@ test('should bubble up errors with destroy call if session expired', async (t) = | |||
const store = { | |||
set (id, data, cb) { cb(null) }, | |||
get (id, cb) { | |||
cb(null, { expires: Date.now() - 1000, cookie: { expires: Date.now() - 1000 } }) | |||
cb(null, { cookie: { expires: new Date(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.
As I explain elsewhere, expires
is supposed to be a Date, not a number
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.
yay, thanks for picking this up!
this[originalHash] = this[hash]() | ||
this.touch() // Needs to happen after originalHash is set, in case maxAge forces an update |
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.
nice!
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 want to make a proper review. So dont merge it
What is up with the failing unit test? |
Interesting -- failing test works locally. It appears to be a race condition somewhere. My guess is that |
…tants to make reading a little easier
Ugh, I'm dumb. The cookie wasn't in So it was making a new session. This would have a fresh
|
To be honest this PR is hard to digest. Can we please fix one issue at a time? |
Co-authored-by: Uzlopak <aras.abbasi@googlemail.com>
@Uzlopak happily! This PR is hard for me to digest too. There were some tests that didn't do what they advertised, which caused a lot of grief for me. I can split it up into a PR that cleans up tests and a PR that does this change, if that helps? |
return Boolean( | ||
this[originalHash] !== this[hash]() || | ||
// If maxAge is set, the session is modified. | ||
// This is necessary because we don't read the cookie's expiration from the cookie itself. | ||
// session.cookie.expires is initially set from Cookie(cookieOpts), so we cannot detect if it changed from maxAge alone. | ||
this[maxAge] | ||
) |
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.
return Boolean( | |
this[originalHash] !== this[hash]() || | |
// If maxAge is set, the session is modified. | |
// This is necessary because we don't read the cookie's expiration from the cookie itself. | |
// session.cookie.expires is initially set from Cookie(cookieOpts), so we cannot detect if it changed from maxAge alone. | |
this[maxAge] | |
) | |
if (this[originalHash] !== this[hash]()) { | |
return true | |
} | |
// If maxAge is set, the session is modified. | |
// This is necessary because we don't read the cookie's expiration from the cookie itself. | |
// session.cookie.expires is initially set from Cookie(cookieOpts), so we cannot detect if it changed from maxAge alone. | |
return this[maxAge] != null |
However, this seems wrong. Just setting a max age should never make isModified
return true
every single time
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 is necessary because we don't read the cookie's expiration from the cookie itself.
We should probably do that, and isn't that what happens with your return sess.cookie.expires?.getTime()
in the hash function?
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.
and isn't that what happens with your... hash function?
I wish!
cookie.expires is set using maxAge upon initialization anyway:
https://github.com/fastify/session/blob/master/lib/cookie.js#L42-L44
But you're right, maxAge
shouldn't auto-trigger a modification. I realized that if maxAge
is set but rolling
is false, we want it to stay.
Also, we probably want to eventually support session stores that implement the touch
method. In this case, the session would not be modified, just the TTL would.
Reverting this but I'm not quite sure how to implement this otherwise... need to think about it
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.
Ah -- I'm mistaken. This code is confusing :)
If rolling
is false, Session.restore will be called, which addresses this.
Guys... really split this PR in some logical parts. I am investigating some time on having some reliable benchmark as the current benchmark sucks currently. But yeah. Please lets split it.If you like we could first agree which are the parts and who wants to implement this or that feature/bug fix. |
Okay I'm going to split this PR up into a bunch of parts:
Sound good? |
Maybe simpler. would say following parts:
|
Just get the PRs as small as possible keep them coming. |
Sounds great. Will update this comments as the PRs come in
|
Closing in favor of: |
Picking up where @SimenB left off here: #101
Checklist
npm run test
andnpm run benchmark
and the Code of conduct
Benchmarks
Running locally. Before:
After: