Allow more control over cookiePrefix
config
#4810
ysfaran
started this conversation in
Feature Requests & Ideas
Replies: 1 comment
-
+1 to this. Have the same problem |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
If you use a SSR framework like Next.js and payload in one server (e.g. like the custom-server example), you will have a problem with the live preview sooner or later.
In my case I use the live preview feature for logged in and logged out states of my Next.js app. For example I have a header global defined which will look different for logged in and logged out users (e.g. only the logged out user will see a login button on the top right). An admin can then change text of buttons and header items.
The problem in my case now is that both, the admin UI (e.g. http://localhost:3000/admin) and the Next.js UI (e.g. http://localhostlocalhost:3000/), use the same user collection for authentication, but the admin user has no access to the Next.js UI and the Next.js user has no access to the admin UI.
When you want to add a live preview to a page where logged in state is required you would ideally login into the admin UI with one account and to the Next.js UI with another account. The problem though is that this is not possible since both application use the same cookie name. So if you log in on the admin UI you wont see the Next.js UI in a logged in state and if you log into the Next.js UI you wont be able to access the admin UI.
There are two ways this could be solved:
cookiePrefix
per collection, not only globally. With this approach you could create two collections, one for admins and one for users. This means you could have a different cookie name for for each UI.cookiePrefix
which gets the current request object, to distinguish between UI'sCurrently I work arround this by using
yarn path
with following diff (payload2.5.0
):In my payload config I can define this:
Obviously this was just a dirty fix and you could still be backwards compatible by allowing a
string
OR a function forcookiePrefix
.If you are happy with the 2. solution I'm glad to open a PR with a proper implementation. (for the 1. solution I would need more time for digging deeper, but could still do it a bit later guess.)
Beta Was this translation helpful? Give feedback.
All reactions