persistent "stay signed in" session cookies across every bchen.dev app (both #18

New Issue

brendan · 2026-05-13T19:02:16Z

brendan commented

2026-05-13 19:02:16 +00:00

Originally filed: 2026-05-08 in ~/features.md, block #16.
Cross-project companion issues: brendan/authd, brendan/buchinese, brendan/dashcam, brendan/inventory, brendan/movement

2026-05-08 — cross-project: persistent "stay signed in" session cookies across every bchen.dev app (both authd-SSO and own-login flows)

User wants: once you sign in to any bchen.dev app, you stay signed in until you explicitly clear your cookies (or hit a logout button). No more "open the laptop next morning and get bounced to /login because the session cookie was a session-only cookie that died with the browser."

Source request (verbatim from user): "for every app (including those using the new authd signin + old individual signin), make it so you stay signed in unless you clear your cookies"

In scope — all 6 apps with auth/session surfaces:

authd (~/authd) — ✅ DONE (PR #7 merged 2026-05-09 at 562aca5). 30-day sliding token cookie + JWT, single mint primitive issueSessionCookie, mfa-pending guard + logout-path guard preserved. JWT_EXPIRY env var dropped.
inventory (~/inventory) — NOT yet an authd client; migration filed as the separate item above (2026-05-08, "migrate inventory authentication to authd … both human login AND MCP"). The migration also rips out inventory's MCP-OAuth-provider surface entirely (per user direction, 2026-05-08). After that lands, inventory has exactly one cookie path — inventory_session set by the authd handshake — and one Bearer-token path for MCP traffic, both keyed by authd sub. Persistence work for inventory then becomes "authd SSO cookie + inventory_session cookie + a long enough sessions-table TTL for MCP refresh-token rotations to keep up". Sequence accordingly: do the migration first, then sweep inventory along with the other authd-SSO clients (inventory, buchinese, dashcam) for the long-Max-Age treatment.
buchinese (~/buchinese) — ✅ DONE (PR #3 merged 2026-05-09 at 9015328). 30-day persistent buchinese_session cookie + sliding renewal at most once per hour. Family constants reused verbatim. Two-layer logout-resurrection defense (architectural + URL guard).
nanodrop (~/nanodrop) — ✅ DONE (PR #4 merged 2026-05-09 at aed9931). 30-day persistent nanodrop_session cookie + sliding renewal at most once per hour. Family constants reused verbatim. Stateless-JWT architecture (mirrors authd; nanodrop has no sessions table). Both logout paths URL-guarded. JWT_EXPIRY env var removed.
dashcam (~/dashcam) — ✅ DONE (PR #2 merged 2026-05-09 at 4459450). 30-day persistent dashcam_session cookie + sliding renewal at most once per hour. Family constants reused verbatim. Stateful sessions-DB architecture (mirrors buchinese). sessions table gained expires_at column with idempotent ALTER + last_seen_at backfill. Two-layer logout-resurrection defense (architectural + URL guard with query-string strip). Tampered-ciphertext hardening (try/catch wrap returns null instead of 500). Single-mint primitive consolidates the cookie write at exactly one site.
movement (~/movement) — ✅ DONE (PR #13 merged 2026-05-10 at be39c07). 30-day persistent movement_session cookie + sliding renewal at most once per hour. Family constants reused verbatim. Stateless-JWT architecture (mirrors authd/nanodrop; movement has no sessions table). Hard-cut rename from token → movement_session. Both logout paths URL-guarded. JWT_EXPIRY env var removed. sameSite='strict' preserved (stricter than family default 'lax', kept per never-relax invariant).

Out of scope: portman, tradebot — no auth surface (verified by survey on 2026-05-08).

What "stay signed in" means in practice (the spec):

Replace session-only cookies with persistent cookies. Today the suspicion is that some/all of these apps set their session cookie without a Max-Age / Expires attribute, which makes the browser drop it when the window closes. Set an explicit long expiry. Recommended default across the family: 30 days, sliding (rolling) — every authenticated request bumps the cookie's expiry forward another 30 days. So an active user effectively never gets logged out; an inactive user's session lapses 30 days after their last visit. The implementer may pick 90 days if there's a reason, but pick one number and use it consistently across all 6 apps so the family feels coherent.
For authd-SSO clients (inventory, buchinese, …): both layers need persistence — the authd SSO cookie at auth.bchen.dev (so re-auth on the SSO server isn't required when an app's local session lapses), AND each downstream app's own session cookie (so the app doesn't bounce through OAuth on every visit). If authd issues refresh tokens, ensure the access-token-refresh path is wired up so a still-valid refresh token avoids bouncing the user to /login.
For own-login apps (nanodrop, dashcam, movement, …): their single session cookie just needs the long Max-Age + sliding-renewal middleware.
Security attributes preserved or strengthened, not relaxed. Every cookie touched must keep Secure, HttpOnly, SameSite=Lax (or Strict where the app already uses it). Cookie value still rotates on login (no fixation). Idle-rolling expiry uses the existing session token; do not extend a token after sign-out.
Logout still ends the session. Explicit logout button → cookie cleared server-side AND a Set-Cookie: <name>=; Max-Age=0 sent to the browser. "Stay signed in unless you clear your cookies" = until cookies expire OR the user actively clears them OR the user clicks logout.
Server-side session record matches. Whatever sliding expiry the cookie uses, the server-side session record (DB row, redis entry, JWT exp claim, etc.) must be aligned — otherwise the cookie says "valid for 30 more days" while the server already considers it expired and bounces the user.

Plan / approach:

Survey pass per app — for each of the 6 repos above, locate where the session cookie is set (search for cookie, Set-Cookie, maxAge, max_age, expires, session). Note current cookie attributes and current server-side session lifetime.
Pick the family-wide constant — 30 days sliding by default. File-level constant (e.g. SESSION_TTL_DAYS = 30) so it's tunable per repo without hunting through the codebase.
Implement per repo — one PR per app. Each PR: (a) cookie attrs updated, (b) sliding-renewal middleware added if missing, (c) server-side session lifetime aligned, (d) logout path verified to still clear cookies + server record, (e) tests covering the new persistence + logout-still-works behavior.
Order: authd first (SSO cookie propagates), then the OAuth clients (inventory, buchinese), then the own-login apps (nanodrop, dashcam, movement). Each PR independent — no cross-repo merge dependency, but landing authd first lets you smoke-test the OAuth-client changes against a long-lived SSO cookie.
Standard implementer pipeline per PR: plan → execute → review → merge.

Acceptance:

For each of the 6 apps: signing in, closing the browser, reopening it the next day → still signed in. (The implementer will need a smoke-test plan covering this — at minimum, set a cookie, kill the browser process, restart, hit the app, expect to land on the authed page not /login.)
For each of the 6 apps: clicking the logout button → bounced to login (and the cookie is gone in devtools).
For each of the 6 apps: clearing site cookies in devtools → bounced to login on next request.
For each of the 6 apps: a session that has not been touched for >TTL_DAYS → bounced to login on next request (the inactive-user lapse case).
No regression in security headers / cookie flags. Secure, HttpOnly, SameSite attributes preserved.
Build + tests green per repo; PRs land on main via the implementer pipeline.

Notes for the implementer:

This is one umbrella ask but it splits cleanly into 6 independent PRs — do not bundle into one mega-PR. File follow-ups back into ~/features.md if any per-app implementation hits a snag that warrants its own item.
If any of the 6 apps already has 30-day-sliding cookies, that PR is a no-op + a confirmation note in the PR description; don't churn the file just to "match" — leave it alone.
The recent inventory PR #5 and authd PR #6 work shows the family is converging on shared conventions; this is in the same spirit. Keep the chosen SESSION_TTL_DAYS constant identical across all 6 repos so future audits are trivial.

Source: user via reporter chat (2026-05-08).

> **Originally filed:** 2026-05-08 in ~/features.md, block #16. > **Cross-project companion issues:** brendan/authd, brendan/buchinese, brendan/dashcam, brendan/inventory, brendan/movement **2026-05-08 — cross-project: persistent "stay signed in" session cookies across every bchen.dev app (both authd-SSO and own-login flows)** User wants: once you sign in to any bchen.dev app, you stay signed in until you explicitly clear your cookies (or hit a logout button). No more "open the laptop next morning and get bounced to /login because the session cookie was a session-only cookie that died with the browser." **Source request (verbatim from user):** "for every app (including those using the new authd signin + old individual signin), make it so you stay signed in unless you clear your cookies"      **In scope — all 6 apps with auth/session surfaces:** - **authd** (`~/authd`) — ✅ **DONE** (PR #7 merged 2026-05-09 at `562aca5`). 30-day sliding `token` cookie + JWT, single mint primitive `issueSessionCookie`, mfa-pending guard + logout-path guard preserved. `JWT_EXPIRY` env var dropped. - **inventory** (`~/inventory`) — **NOT yet an authd client; migration filed as the separate item above** (2026-05-08, "migrate inventory authentication to authd … both human login AND MCP"). The migration also rips out inventory's MCP-OAuth-provider surface entirely (per user direction, 2026-05-08). After that lands, inventory has exactly one cookie path — `inventory_session` set by the authd handshake — and one Bearer-token path for MCP traffic, both keyed by authd `sub`. Persistence work for inventory then becomes "authd SSO cookie + `inventory_session` cookie + a long enough `sessions`-table TTL for MCP refresh-token rotations to keep up". Sequence accordingly: do the migration first, then sweep inventory along with the other authd-SSO clients (inventory, buchinese, dashcam) for the long-Max-Age treatment. - **buchinese** (`~/buchinese`) — ✅ **DONE** (PR #3 merged 2026-05-09 at `9015328`). 30-day persistent `buchinese_session` cookie + sliding renewal at most once per hour. Family constants reused verbatim. Two-layer logout-resurrection defense (architectural + URL guard). - **nanodrop** (`~/nanodrop`) — ✅ **DONE** (PR #4 merged 2026-05-09 at `aed9931`). 30-day persistent `nanodrop_session` cookie + sliding renewal at most once per hour. Family constants reused verbatim. Stateless-JWT architecture (mirrors authd; nanodrop has no sessions table). Both logout paths URL-guarded. `JWT_EXPIRY` env var removed. - **dashcam** (`~/dashcam`) — ✅ **DONE** (PR #2 merged 2026-05-09 at `4459450`). 30-day persistent `dashcam_session` cookie + sliding renewal at most once per hour. Family constants reused verbatim. Stateful sessions-DB architecture (mirrors buchinese). sessions table gained `expires_at` column with idempotent ALTER + `last_seen_at` backfill. Two-layer logout-resurrection defense (architectural + URL guard with query-string strip). Tampered-ciphertext hardening (try/catch wrap returns null instead of 500). Single-mint primitive consolidates the cookie write at exactly one site. - **movement** (`~/movement`) — ✅ **DONE** (PR #13 merged 2026-05-10 at `be39c07`). 30-day persistent `movement_session` cookie + sliding renewal at most once per hour. Family constants reused verbatim. Stateless-JWT architecture (mirrors authd/nanodrop; movement has no sessions table). Hard-cut rename from `token` → `movement_session`. Both logout paths URL-guarded. `JWT_EXPIRY` env var removed. `sameSite='strict'` preserved (stricter than family default 'lax', kept per never-relax invariant). **Out of scope:** portman, tradebot — no auth surface (verified by survey on 2026-05-08). **What "stay signed in" means in practice (the spec):** 1. **Replace session-only cookies with persistent cookies.** Today the suspicion is that some/all of these apps set their session cookie without a `Max-Age` / `Expires` attribute, which makes the browser drop it when the window closes. Set an explicit long expiry. Recommended default across the family: **30 days, sliding (rolling)** — every authenticated request bumps the cookie's expiry forward another 30 days. So an active user effectively never gets logged out; an inactive user's session lapses 30 days after their last visit. The implementer may pick 90 days if there's a reason, but pick **one** number and use it consistently across all 6 apps so the family feels coherent. 2. **For authd-SSO clients (inventory, buchinese, …):** both layers need persistence — the **authd SSO cookie** at `auth.bchen.dev` (so re-auth on the SSO server isn't required when an app's local session lapses), AND each downstream app's own session cookie (so the app doesn't bounce through OAuth on every visit). If authd issues refresh tokens, ensure the access-token-refresh path is wired up so a still-valid refresh token avoids bouncing the user to `/login`. 3. **For own-login apps (nanodrop, dashcam, movement, …):** their single session cookie just needs the long Max-Age + sliding-renewal middleware. 4. **Security attributes preserved or strengthened, not relaxed.** Every cookie touched must keep `Secure`, `HttpOnly`, `SameSite=Lax` (or `Strict` where the app already uses it). Cookie value still rotates on login (no fixation). Idle-rolling expiry uses the existing session token; do not extend a token after sign-out. 5. **Logout still ends the session.** Explicit logout button → cookie cleared server-side AND a `Set-Cookie: <name>=; Max-Age=0` sent to the browser. "Stay signed in unless you clear your cookies" = until cookies expire OR the user actively clears them OR the user clicks logout. 6. **Server-side session record matches.** Whatever sliding expiry the cookie uses, the server-side session record (DB row, redis entry, JWT exp claim, etc.) must be aligned — otherwise the cookie says "valid for 30 more days" while the server already considers it expired and bounces the user. **Plan / approach:** 1. **Survey pass per app** — for each of the 6 repos above, locate where the session cookie is set (search for `cookie`, `Set-Cookie`, `maxAge`, `max_age`, `expires`, `session`). Note current cookie attributes and current server-side session lifetime. 2. **Pick the family-wide constant** — 30 days sliding by default. File-level constant (e.g. `SESSION_TTL_DAYS = 30`) so it's tunable per repo without hunting through the codebase. 3. **Implement per repo** — one PR per app. Each PR: (a) cookie attrs updated, (b) sliding-renewal middleware added if missing, (c) server-side session lifetime aligned, (d) logout path verified to still clear cookies + server record, (e) tests covering the new persistence + logout-still-works behavior. 4. **Order:** authd first (SSO cookie propagates), then the OAuth clients (inventory, buchinese), then the own-login apps (nanodrop, dashcam, movement). Each PR independent — no cross-repo merge dependency, but landing authd first lets you smoke-test the OAuth-client changes against a long-lived SSO cookie. 5. **Standard implementer pipeline per PR:** plan → execute → review → merge. **Acceptance:** - For each of the 6 apps: signing in, closing the browser, reopening it the next day → still signed in. (The implementer will need a smoke-test plan covering this — at minimum, set a cookie, kill the browser process, restart, hit the app, expect to land on the authed page not `/login`.) - For each of the 6 apps: clicking the logout button → bounced to login (and the cookie is gone in devtools). - For each of the 6 apps: clearing site cookies in devtools → bounced to login on next request. - For each of the 6 apps: a session that has not been touched for >TTL_DAYS → bounced to login on next request (the inactive-user lapse case). - No regression in security headers / cookie flags. `Secure`, `HttpOnly`, `SameSite` attributes preserved. - Build + tests green per repo; PRs land on `main` via the implementer pipeline. **Notes for the implementer:** - This is one umbrella ask but it splits cleanly into 6 independent PRs — do not bundle into one mega-PR. File follow-ups back into `~/features.md` if any per-app implementation hits a snag that warrants its own item. - If any of the 6 apps already has 30-day-sliding cookies, that PR is a no-op + a confirmation note in the PR description; don't churn the file just to "match" — leave it alone. - The recent `inventory PR #5` and `authd PR #6` work shows the family is converging on shared conventions; this is in the same spirit. Keep the chosen `SESSION_TTL_DAYS` constant identical across all 6 repos so future audits are trivial. Source: user via reporter chat (2026-05-08).

brendan added the feature label 2026-05-13 19:02:16 +00:00

brendan closed this issue

2026-05-13 19:02:16 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: brendan/nanodrop#18