-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Added domain option to session #4951
Conversation
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/keystonejs/keystone-next-docs/AHwgm6GqKmtY9tAfyCrcre7Rs3qW |
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.
Hi @yannick1691, thanks for the PR. I think this is a helpful change. To get it through could I get you to address the linting issues. I suspect it just needs trailing commas after domain
, or you can run yarn format
.
Also, could you please update the docs in docs-next/pages/api/session.mdx
to include this option.
Thanks!
🦋 Changeset detectedLatest commit: f8236ed The changes in this PR will be included in the next version bump. This PR includes changesets to release 8 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Hi @timleslie , thank you for the fast response. I have implemented the suggested changes and have updated the documentation. For the documentation I looked at the MDN specs of the domain property. I also link to the MDN page, but still mentioned some of the key parts of the domain property so that users don't miss those. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#attributes |
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 looks great, thanks @yannick1691 🙏
This adds the option for users to specify a domain for the session that is then used in the cookie.
Use case of this feature
We ran into an issue where we had keystone running at api.domain.com, this caused the cookie domain to be set to api.domain.com.
We then had a use case for the cookie at example.domain.com, however this domain doesn't have access to the cookie.
Allowing the user to set the domain allows them to set it to:
domain.com
This would also solve #4674 for keystone-next