Artifact Site Cookie Bridge and Pub-Host Session Persistence
How the pub host turns a short-lived `gpx_token` redirect parameter into a `gpx_pub_token` cookie, and what that temporary cookie means for signed viewers who keep browsing the published site.
Artifact Site Cookie Bridge and Pub-Host Session Persistence
Where you see this in the app
This page documents what happens after the main app sends a signed viewer to the pub host and the pub host converts that temporary access bridge into a cookie.
Users usually notice this only indirectly, because the site keeps loading normally on the pub host after the first redirect.
Why the pub host sets a cookie
The initial redirect token is only there to complete the cross-host handoff.
Once the viewer reaches the pub host, the app needs a way to persist that short signed-viewer state for subsequent requests on the published-site host. That is why the pub host sets a temporary cookie instead of requiring the same query parameter on every file request.
From an end-user perspective, this keeps published-site browsing practical once the first signed handoff has already succeeded.
gpx_token to gpx_pub_token
The bridge works in two phases:
| Phase | What happens |
|---|---|
Redirect arrives with gpx_token | The pub host verifies the short-lived signed token from the app host |
| Clean redirect response | The pub host strips the query token from the URL and sets gpx_pub_token as a cookie |
| Later pub-host requests | The pub host can keep recognizing the same signed viewer from the cookie |
This matters because a published site often needs more than one request to load fully. HTML, CSS, JavaScript, and API-style pub-host requests can all depend on that persisted viewer state.
Lifetime and limited scope
The pub-host cookie is intentionally limited.
Users should think of it as:
- short-lived,
- scoped to pub-host viewing,
- meant for access continuity rather than long-term account sign-in.
It is not a replacement for the main app session. It is a narrow bridge so the published site can keep serving the current signed viewer for a limited window.
What users should and should not assume
Users should assume:
- the cookie exists to keep the pub-host viewing session working,
- the original query token should disappear from the final clean URL,
- the cookie may stop working after its short access window expires.
Users should not assume:
- this cookie is a reusable personal API token,
- it creates permanent sign-in on the main app host,
- it bypasses later purchase or sign-in checks forever.
If the viewer loses access later, that usually means the temporary bridge expired or a normal access rule still applies.
Related docs
Related docs
See it in action
Previous
Artifact Site Pub-Token and Signed Viewer Handoff
How signed-in viewers are handed off from the main app to the pub host, why a short-lived token is added for that redirect, and what users should understand about that access bridge.
Next
Artifact Attachment Replacement and Commit Flow
How single-file artifact attachment replacement works for authors, what upload URL and commit mean in practical terms, and how this differs from publishing a multi-file artifact site.