You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
id(web): redirect to a clean URL after exchanging a bootstrap token for a cookie #5746
The web-token bootstrap accepts a bearer token in the query string and sets a cookie, but does not remove the token from the browser URL. In pkgs/id/src/web/security.rs around lines 191-218, the CLI directs users to open the token URL (pkgs/id/src/cli.rs:434-439). After cookie issuance the query remains in browser history and can leak through copied URLs, same-origin Referer headers, and access logs.
Existing tests prove cookie creation but do not assert URL cleanup (security.rs around lines 465-484).
Required behavior
After successful bootstrap, set the cookie and redirect to the same request path without the token parameter. Build the target from the validated request path; do not accept an arbitrary redirect destination. Keep other query parameters only if the contract requires them.
Acceptance criteria
A successful bootstrap sets the auth cookie and redirects to the clean same-origin path.
The Location header contains no token value or token parameter.
Missing or invalid tokens behave as before and issue no cookie.
Tests cover redirect status, cookie flags, and the handling of permitted query parameters.
Agent: queue worker (repo-worker-code), lane code-r
Session / ID: task 10159
Found via: queue claim
Task: Triage of the bootstrap-token URL leak at current main.
Expectation: triaged — bug confirmed, fix enqueued as task 10530; issue stays open for that fix.
Links: follow-up task 10530 (small_fix, queued)
Triage findings (task 10159, 2026-11-05)
Confirmed on current main (04f7869), exactly as filed. In pkgs/id/src/web/security.rs, the middleware accepts the query token (ok_query), sets the id_token cookie when ok_query && !ok_cookie, then runs the handler and returns its response with Set-Cookie appended — there is no redirect anywhere in the middleware, so the bearer token remains in the browser URL, history, Referer headers, and access logs. The existing bootstrap test (~lines 465–484) asserts status 200 and the cookie flags only; nothing asserts a Location header. PR search for this issue/bootstrap redirect found no existing or in-flight fix. Issue #2090-style blockers: none; no hard-stop labels.
Fix enqueued as task 10530 (small_fix): on successful query-token bootstrap, short-circuit with a redirect (Set-Cookie unchanged) whose Location is built only from the validated request path with the token parameter removed and other query parameters preserved — never from a parameter or header, so no open redirect. Bearer/cookie paths and the missing/invalid-token 401 behavior stay unchanged. Tests: redirect status + cookie flags, Location carries no token param/value, invalid token still 401 with no cookie, cookie-auth request still succeeds without a redirect.
Result: PR id(web): redirect to clean URL after bootstrap token exchange (#5746) #6236 merged (merge commit ffdd4f5); this issue auto-closed by the merge. GET query-token bootstrap now answers 303 to the same path with the token parameter removed (other parameters preserved), Set-Cookie riding the redirect; non-GET and cookie/bearer auth unchanged.
Tests: cargo test --features web web::security on the laptop worktree — 17 passed, 0 failed, including the updated bootstrap test and three new ones (param preservation + token absence in Location, cookie-auth no-redirect, invalid token 401/no-cookie/no-redirect). PR checks were still queued at merge time (congested CI); merged under the standing merge authority on the verified targeted tests. Note for local runs: the crate's web feature needs pkgs/id/web/dist present (git-ignored build output) or RustEmbed fails — the worktree borrowed the primary clone's dist via symlink.
Activity
developing-today commentedon Nov 5, 2026
CODE-1436
dezren39 commentedon Nov 5, 2026
🤖 Agent note · done (triaged)
Triage findings (task 10159, 2026-11-05)
Confirmed on current main (04f7869), exactly as filed. In
pkgs/id/src/web/security.rs, the middleware accepts the query token (ok_query), sets theid_tokencookie whenok_query && !ok_cookie, then runs the handler and returns its response withSet-Cookieappended — there is no redirect anywhere in the middleware, so the bearer token remains in the browser URL, history, Referer headers, and access logs. The existing bootstrap test (~lines 465–484) asserts status 200 and the cookie flags only; nothing asserts a Location header. PR search for this issue/bootstrap redirect found no existing or in-flight fix. Issue #2090-style blockers: none; no hard-stop labels.Fix enqueued as task 10530 (small_fix): on successful query-token bootstrap, short-circuit with a redirect (Set-Cookie unchanged) whose Location is built only from the validated request path with the
tokenparameter removed and other query parameters preserved — never from a parameter or header, so no open redirect. Bearer/cookie paths and the missing/invalid-token 401 behavior stay unchanged. Tests: redirect status + cookie flags, Location carries no token param/value, invalid token still 401 with no cookie, cookie-auth request still succeeds without a redirect.3 remaining items
developing-today commentedon Nov 5, 2026
🤖 Agent note · picked up
Merge pull request #6236 from developing-today/queue/10530-5746-boots…
developing-today commentedon Nov 5, 2026
🤖 Agent note · done