Open
Conversation
Introduces a new option, 'sessionName', which is the key under `Express.Request.sessions` where the session can be accessed. 'session' is the default sessionName, and sessions with sessionName 'session' are still accessible at `Express.Request.session`. This API was chosen to avoid breaking existing applications. Rejected alternative APIs: - The `name` property acts as the session accessor on `req.sessions`. Either obviating the need for the `sessionName` option, or perhaps allowing the `sessionName` to default to `name`. This would be a breaking change in all apps that provide a non-default value for `name`. I considered working around this by always making the first cookie-session created the one accessible at `req.session`, but this felt hacky and potentially confusing. - Each session is accessed by adding its sessionName as a property on `req`. I feared this would pollute the namespace, risking name collisions with other modules.
Users can now pass several, or an array of, options objects to `cookieSession`. One middleware function will always be returned that creates all the sessions. This means that users using multiple cookie-sessions in their app never need to call `cookieSession` multiple times. `cookieSession` now also checks that the sessions have unique names and sessionNames to avoid tricky overwriting bugs. I rejected an alternative approach, in which `cookieSession` returns an array of middleware functions. You can pass Express an array of middleware exactly like passing a single functions, so it wouldn't break any user's apps in those cases. But we can't assume that all users are passing the function straight to Express.
Bumps actions/checkout from v2 to v3 Uses latests Ubuntu version for tests Because actions using Node12 are being deprecated: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Enables the user to create arbitrarily many cookie-sessions, whose options can differ. The API design was motivated by ensuring backwards compatibility with v2 (more details in the Discussion below).
Fixes:
The new features are pretty comprehensively tested, and I'm using them in production. But I'm still happy to discuss alternative APIs/implementations. I've also got a sister fork of Definitely Typed with updated typings. I'll create a PR there when this gets merged.
I'm requesting to merge into master because I noticed that you have some WIP changes on develop.
Example
A fairly complex example taken from the new tests to illustrate the new features:
Discussion
I tend to discuss the "why", including rejected alternative designs, in my commit messages. But I've basically reproduced that commentary here for convenience.
Enable setting multiple cookie-sessions
Introduces a new option, 'sessionName', which is the key under
Express.Request.sessionswhere the session can be accessed. 'session' is the default sessionName, and sessions with sessionName 'session' are still accessible atExpress.Request.session. This API was chosen to avoid breaking existing applications.Rejected alternative APIs:
nameproperty acts as the session accessor onreq.sessions. Either obviating the need for thesessionNameoption, or perhaps allowing thesessionNameto default toname. This would be a breaking change in all apps that provide a non-default value forname. I considered working around this by always making the first cookie-session created the one accessible atreq.session, but this felt hacky and potentially confusing.req. I feared this would pollute the namespace, risking name collisions with other modules.Call cookieSession with multiple options objects
Users can now pass several, or an array of, options objects to
cookieSession. One middleware function will always be returned that creates all the sessions. This means that users using multiple cookie-sessions in their app never need to callcookieSessionmultiple times.cookieSessionnow also checks that the sessions have unique names and sessionNames to avoid tricky overwriting bugs.I rejected an alternative approach, in which
cookieSessionreturns an array of middleware functions. You can pass Express an array of middleware exactly like passing a single functions, so it wouldn't break any user's apps in those cases. But we can't assume that all users are passing the function straight to Express.