Reliable editor toolbar behind shared caches: opt-in client-side toolbar bootstrap

[swissky]

Problem

The editor toolbar (the floating pill for authenticated editors) is injected server-side: the request-context middleware rewrites the HTML response (injectToolbar) whenever locals.user has role >= 30. Since #1398 these toolbar-bearing responses correctly send Cache-Control: private, no-store, so they are never stored in a shared cache.

That fix has a structural consequence on any site whose public HTML is served through a shared cache — Cloudflare "Cache Everything" / the new Workers Cache, Fastly, Varnish, Cloudront, etc.:

• The cache sits in front of the server and cannot vary or bypass on the session cookie (and Vary: Cookie would fragment the cache into uselessness even where it is honored).
• So a logged-in editor browsing the public site gets the cached anonymous variant — without the toolbar — whenever an anonymous visitor primed the cache first.
• The editor only sees the toolbar on cache MISSes, which makes it appear and disappear unpredictably as they navigate. Meanwhile their own (toolbar-injected, no-store) renders never refresh the cache.

Today the workarounds are "wait for the TTL" or "add a random query param to force a MISS" — neither is something you can tell an editor with a straight face.

Idea: opt-in client-side toolbar bootstrap

Make the toolbar independent of the HTML variant the cache serves:

1. Marker cookie on login. When a session is created, additionally set a non-HttpOnly, non-sensitive marker cookie (e.g. emdash-editor=1 — no token, no user data; it only means "a session may exist"). Cleared on logout / session expiry.
2. Tiny bootstrap script on public pages. A few hundred bytes, inline or as a static asset: if the marker cookie is absent, do nothing (anonymous visitors pay zero cost — no extra request, no layout work). If present, do a credentialed fetch to a small private, no-store session endpoint (e.g. GET /_emdash/api/toolbar-state returning { editor: boolean, editMode: boolean }) and, if the user is an editor, inject the toolbar client-side.
3. Cached HTML becomes identical for everyone. No per-session HTML rewriting on public pages, nothing session-specific to leak into shared caches, and editors get a reliable toolbar regardless of cache state. The no-store guard from Editor toolbar injection doesn't set Cache-Control: private, no-store, poisoning shared CDN caches #1398 stays for the remaining server-injection paths (preview, edit mode).

Scope / design notes

• Opt-in (config flag, e.g. toolbar: "client"), keeping the current server-side injection as the default — zero behavior change for existing sites.
• Preview mode and edit mode (emdash-edit-mode cookie) already force private, no-store server renders and would keep working as they do today; the client bootstrap only covers the "editor browsing the public site" case.
• The marker cookie carries no secret; a forged cookie only triggers one extra fetch that returns { editor: false }.
• Needs a CSP-friendly delivery (external script or documented nonce/hash) rather than an inline <script>.

Happy to build this and open a PR if maintainers think the approach fits. Also open to alternatives — e.g. shipping the bootstrap as part of an existing script EmDash already injects, or documenting a recommended cache-bypass pattern instead.

[ascorbic]

Unfortunately this wouldn't work. It would allow the toolbar to display, but wouldn't allow the actual editing, because that still needs to send different HTML. It would either need something like an edit query param added to every URL (probably including injecting it into internal links), or use a gateway Worker (which would only work on Cloudflare) that conditionally returns the cached or uncached version depending on the presence of a cookie.

[swissky]

For me, one of the easiest ways would be to set a setting to deactivate the Toolbar. Nobody is using it in our team. That's more of a second way and an option for users. It does not solve the discussion I started

[MA2153]

@swissky Fair, same here. I once sent a PR that would temporarily kill it, but I learned it's actually wired in and "usable" and some optimizations have even been disabled to make it work...

There is a related issue though: previews. Those always need fresh content too.

[ascorbic]

I think query param is the best option, with an early redirect return if the user is logged-out. That way if the user shares a URL with the param it's fine because the logged-out user will be redirected to the canonical version. Thinking more about it, I don't think it's even needed to append it to internal links: you probably don't want it to persist on navigation anyway.

I think the ideal solution would be two parts:

• the toggle is rendered client-side, based on (non-secret) flag stored in localStorage when you login.
• clicking on the toggle checks the login status and if not logged-in it takes you to the login page, and if logged-in it takes you to the page with the query param, which checks for the login cookie, and is rendered without caching
• the ability to disable it entirely in config, and to dismiss it in the browser

[MA2153]

Sounds good

[ascorbic]

OK, I've labelled this so if anybody would like to take this on then please do

[swissky]

@-

[swissky]

PR is up: #1886 — implements the two-part design from above (client-rendered toggle from a non-secret localStorage flag, _edit query param with an early canonical redirect for logged-out visitors, toolbar: false to disable in config, and a dismiss button in the browser).