golem15/summercms
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: fold G3 leftovers into G4 and login-cookie quicks

Browse Source
This commit is contained in:
Jakub Zych
2026-10-22 22:00:09 +02:00
parent 98a95c9c92
commit b8bf71c5dd
3 changed files with 14 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
.planning/todos/pending/2026-10-22-user-login-opt-in-session-cookie.md
View File

@@ -26,6 +26,8 @@ Phase 19.6 (2FA) is not mid-flight; `Login()` is free to change.
Opt-in config on the user plugin (decide the key in `--discuss`: reuse a shared `auth.cookie` / bouncer cookie config, or a `golem15.user.jwt.token_cookie` twin of sociallogin). Default off, body still carries `token` unless the discuss decision matches sociallogin’s “cookie set, token omitted”. Cookie attributes from `bouncer.LoadCookieConfig`. No cookie when the flag is off (current contract).
`--discuss` also locks: (1) a cookie-carried `/refresh` must rewrite the session cookie (G3 left body-only rotate, which is unusable for an HttpOnly cookie the browser cannot store); follow `bouncer.CookieRefreshHandler`. (2) keep SameSite=Lax and do not add a CSRF token — that is the existing `jwt.auth` POST story (`/tokens`, `/logout`). Do not switch the cookie to SameSite=None.
After the commit, fill item 7 in `.planning/notes/2026-10-22-external-user-plugin-escalations.md`.
## Note from G3 (2026-10-22)
@@ -35,5 +37,5 @@ Since sm-user-plugin `8e4b863`, `POST /refresh` accepts the `token` and `auth_to
## Invoke
```
/msd-quick --discuss --validate Opt-in HttpOnly session cookie on user-plugin POST /login, following sociallogin token_cookie / bouncer.LoadCookieConfig. Default off so existing body-token clients stay unchanged. See .planning/todos/pending/2026-10-22-user-login-opt-in-session-cookie.md and .planning/notes/2026-10-22-external-user-plugin-escalations.md
/msd-quick --discuss --validate Opt-in HttpOnly session cookie on user-plugin POST /login, following sociallogin token_cookie / bouncer.LoadCookieConfig. Default off. Discuss: a cookie-carried /refresh must rotate that cookie (G3 left body-only); keep SameSite=Lax, no new CSRF token. See .planning/todos/pending/2026-10-22-user-login-opt-in-session-cookie.md and .planning/notes/2026-10-22-external-user-plugin-escalations.md
```

8
.planning/todos/pending/2026-10-22-user-logout-blacklist-missing-under-serve.md
View File

@@ -24,10 +24,14 @@ Confirmed. `party.Activate` (and every plugin `Boot`) runs in generated `main` b
Use `lagoon.OnDatabase` from `Boot` (the documented seam: lighthouse and beachcomber already do). On publish: install `RegisterHooks`, publish `bouncer.NewPostgresBlacklist(sqlDB, "jwt_blacklist")`, and give the jwt guard that store (re-register, or a lazy store that `Lookup`s at request time — decide in `--discuss`). A test must boot like `serve`: Activate/Boot, then Publish, then login + logout + jwt.auth 401 and a blacklist row. A test that publishes first is not enough.
After the commit, fill G4 in `.planning/notes/2026-10-22-external-user-plugin-escalations.md`.
**G3 leftover:** `plugin.go` still registers the jwt guard with the cookie names written out (`"token", "auth_token"`). G3 exported `classes.SessionCookieNames()` and the controllers already pass it. When this quick reworks that `Register` line, switch to `classes.SessionCookieNames()...` so the guard and `SessionToken` cannot drift. Until then `TestSessionRoutesAcceptCookies` is the drift net.
Base is sm-user-plugin `8e4b863` (G3). Hold push/tag for SummerCMS v0.5.0.
After the commit, fill G4 in `.planning/notes/2026-10-22-external-user-plugin-escalations.md` the same way as G2/G3 (`done (unreleased)`, ships in v0.5.0). Leave the todo in pending with an Outcome.
## Invoke
```
/msd-quick --discuss --validate Under serve, user-plugin Boot runs before lagoon.Publish so the jwt blacklist is never wired and logout does not revoke. Wire BlacklistStore and RegisterHooks through lagoon.OnDatabase; test Activate-then-Publish. See .planning/todos/pending/2026-10-22-user-logout-blacklist-missing-under-serve.md and .planning/notes/2026-10-22-external-user-plugin-escalations.md
/msd-quick --discuss --validate Under serve, user-plugin Boot runs before lagoon.Publish so the jwt blacklist is never wired and logout does not revoke. Wire BlacklistStore and RegisterHooks through lagoon.OnDatabase; test Activate-then-Publish. When re-registering the jwt guard, pass classes.SessionCookieNames() instead of the hardcoded token/auth_token names (G3 leftover). See .planning/todos/pending/2026-10-22-user-logout-blacklist-missing-under-serve.md and .planning/notes/2026-10-22-external-user-plugin-escalations.md
```