fix: never store an answer that depends on the token cookie #45

2026-09-09T19:52:13+02:00

mi commented

2026-09-09 19:52:13 +02:00

Since PR#43 a page and every JSON answer differ by the control-token cookie,
and both were sent without a single caching header. So a browser could
redisplay the copy it already had after a token was pasted, which is what made
a newly entered token look ineffective — and a shared cache in front of
Werkator was free to hand one visitor's answer to another, in the worst case
the operator's page with every repository named.

The pages and the JSON APIs are no-store now and say they vary by cookie.
Artifact files keep the caching they have, because a report is large and never
changes under its key; they only state the dependency, which is enough for a
correct shared cache.

The key in the header asks before forgetting the token, and after taking one it
fetches the address afresh instead of reloading.

Co-Authored-By: Claude Fable 5.1 noreply@anthropic.com

Since PR#43 a page and every JSON answer differ by the control-token cookie, and both were sent without a single caching header. So a browser could redisplay the copy it already had after a token was pasted, which is what made a newly entered token look ineffective — and a shared cache in front of Werkator was free to hand one visitor's answer to another, in the worst case the operator's page with every repository named. The pages and the JSON APIs are no-store now and say they vary by cookie. Artifact files keep the caching they have, because a report is large and never changes under its key; they only state the dependency, which is enough for a correct shared cache. The key in the header asks before forgetting the token, and after taking one it fetches the address afresh instead of reloading. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

mi added 1 commit 2026-09-09 19:52:13 +02:00

server: never store an answer that depends on the token cookie d9fce85a8f

Since PR#43 a page and every JSON answer differ by the control-token cookie,
and both were sent without a single caching header. So a browser could
redisplay the copy it already had after a token was pasted, which is what made
a newly entered token look ineffective — and a shared cache in front of
Werkator was free to hand one visitor's answer to another, in the worst case
the operator's page with every repository named.

The pages and the JSON APIs are no-store now and say they vary by cookie.
Artifact files keep the caching they have, because a report is large and never
changes under its key; they only state the dependency, which is enough for a
correct shared cache.

The key in the header asks before forgetting the token, and after taking one it
fetches the address afresh instead of reloading.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

mi added 1 commit 2026-09-09 19:54:02 +02:00

docs(prs): PR#45 for the token cookie and the caching headers afc950b6bc

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

mi merged commit 3578aeb0fb into main

2026-09-09 20:05:12 +02:00

mi deleted branch token-button

2026-09-09 20:05:12 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mi/werkator#45