Replies: 1 comment
-
I've collected a couple of examples where the workaround is currently either documented or implemented by CMS providers: I think it's safe to assume that there also plenty of custom implementations. All these implementations could easily break in the future if changes are being made to the current implementation as these dependencies are not transparent. |
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.
Uh oh!
There was an error while loading. Please reload this page.
-
Goals
Allow seamless integration of Draft Mode with headless CMSes which utilize Iframes as visual preview
Non-Goals
No response
Background
Currently the only way (known to me) to make Draft Mode work in the described setting "seamlessly", seems to be a workaround which relies on implementation details of Next's otherwise unexposed handling of the Draft Mode: reading the
__prerender_bypass
cookie after set by Next and replacing theSameSite
attribute manually before it's actually set. Described e.g. in #49927.This probably affects most Next Apps utilizing such a CMS as the alternative is impeding the experience when working with the CMS e.g. opening the route enabling Draft Mode manually in a separate browser window.
Proposal
Add an option
draftModeSameSiteNone
orprerenderBypassSameSiteNone
to the Next Config, which sets theSameSite
attribute on the__prerender_bypass
cookie tonone
.Secure
is already enforced outside of dev mode and doesn't need to be adjusted.As this technically downgrades security I would suggest to implement this as an opt-in-only feature.
Beta Was this translation helpful? Give feedback.
All reactions