Replies: 2 comments
-
The proper way as I understand, and as I've done it is to only use Payload as the access control source of truth.
Then, whenever you need to call the API to get the drafts, you add If you're running PayloadCMS and your FE on the same domain it should just work. However, if you're calling PayloadCMS from your BE or server side framework (like next.js), you will need to make sure you pass the cookie to the request something, like this:
Or you can authenticate via JWT in the Authorisation header, like this: |
Beta Was this translation helpful? Give feedback.
-
If you want sharable preview urls you could have a Then you would attach that to the preview url, like And you could verify that these match in the That way your sessions are safe and outsiders can preview stuff by being shared the preview key for the particular document / entity. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Payload has documentation on setting up previews, but how am I supposed to implement draft previews? In other words:
The question is - where could that
token
come from?I know that Payload provides the user's JWT token in
GeneratePreviewURLOptions
. I could add it in the URL like so:Then, my front-end server could use the JWT token in its calls to Payload to display the content.
However, this opens up opportunities for session hijacking. If I send the preview URL to someone, they could copy the JWT token from the URL and manually put it in a
payload-token
cookie. This would give them access to the admin and they'll be authenticated as me. That's not good.What would be the proper way to implement this?
Beta Was this translation helpful? Give feedback.
All reactions