How to properly switch between published and draft version without exposing preview token to client?

[alexkramer98]

So, my current method looks like this:

1. site gets visited.
2. query gets checked and verified against my preview token, stored in .env and passed in runtimeConfig as a private variable.
3. useAsyncStoryblok gets called with correct version parameter, either published or draft, determined by the previous step.

I have abstracted this logic away in a composable (as this issue does not seem to have been picked up yet). This way I do not have to implement this logic in every call.

This works just fine when initially loading a page. The data only gets fetched on the server.

However, when navigating to a different page, the browser makes the request for the new data to the Storyblok API, exposing (leaking) the preview token.

I could use the public token when the criteria for draft mode do not match, and the preview token elsewhere. But Storyblok's accessToken is not dynamic, since it is injected in nuxt.config.ts.

I see no way but to use storyblok-js-client in favor of storyblok-nuxt at the moment.

How would I fetch the correct version, using SSR, without leaking the preview token to the browser?

Then, there is also the issue of pagination. When updating a query parameter, say, page, I would like to load the correct page. This, too makes the browser perform the request, leaking the token. I currently call an /api route (defined in server/), which proxies the request to the api, so the request to the Storyblok API is done by the server. I am unable to use storyblok-nuxt in here as I keep getting this error. Thus why my current workaround is to use storyblok-js-client instead.

Could anyone shed some light on this?

[saschaglo]

Any clue from someone? Facing the same problem right now.

[oezkancodes]

@alexkramer98 an alternative would be to separate production and preview. You could put the preview on a subdomain, like preview.my-domain.com, and reveal the private key only there. I use this strategy mainly because I pre-render my sites with Nuxt. This also has the advantage that the script for Storyblok Bridge can be disabled on production, so it doesn't have to be loaded as extra baggage for each user. You can additionally protect your subdomain with basic auth, so no one ever can have access to your private key.

[alvarosabu]

I echo what @oezkancodes, netlify allows to have several branch deploys, so I have a production like "staging" using draft api

[oezkancodes]

I have written a blog post on the multi-branch approach that I have suggested. Maybe it will help some people.

https://thenextbit.de/en/blog/storyblok-multi-branch-preview-environment-nuxt-3-static