Having preview secret checked into the sourcecode

[fellmirr]

Hi!

I'm slightly confused about the purpose of the next preview secret. In the example and the accompanying article, the secret is simply checked into source control and openly available, also via the source code served to the client. This strikes me as rather strange, at least when the terminology of "secret" is used. Usually in an authentication context, keeping secrets hidden is highly important.

My understanding is that since we are not really granting any ability to mutate data through the preview api endpoint, this is probably fine, but why bother with a secret in the first place then?

I'm also concerned that it's not sufficiently stressed why this is okay in this context, and I'm worried that novice developers may get the impression that this is a perfectly acceptable method for storing "secret" values :)

Thanks!

[SimeonGriggs]

Hey,

You're not wrong. The word secret here might be misused since it's not really protecting something private – just a very simple way to create an authenticated server-side Client to fetch a draft. Without using an actual API Token in plain text.

So the visitor sees a draft page initially, but doesn't receive continued live updates unless logged in.

If your dataset contains actual sensitive information, it would be best to not only change that to client-side only authentication, but also switch to a private dataset.

There's probably a separate article in better securing and authenticating live previews – this demo was deliberately as simple as possible to get people started.