docs(quick-261022-vfz): user-plugin /login throttle via surf.ClientIP and whole-second tokens_valid_after writers
This commit is contained in:
@@ -27,8 +27,8 @@ Reviewed 2026-10-22. The list is `golem15.user` (sm-user-plugin), not cabana adm
|
||||
| 6 | G8 API token guard ignores `tokens_valid_after` | Decline | — | — | declined | n/a |
|
||||
| 7 | Cookie option on `/login` | Feature | [2026-10-22-user-login-opt-in-session-cookie.md](../todos/pending/2026-10-22-user-login-opt-in-session-cookie.md) | strnsccy | open | |
|
||||
| 8 | Password-routes 404 switch | Feature | [2026-10-22-user-password-routes-404-switch.md](../todos/pending/2026-10-22-user-password-routes-404-switch.md) | h7yrafgd | open | |
|
||||
| 9 | Lockout keyed on `RemoteAddr` | Fix | with 10: [2026-10-22-user-login-lockout-and-same-second-cutoff.md](../todos/pending/2026-10-22-user-login-lockout-and-same-second-cutoff.md) | sniewiif | open | |
|
||||
| 10 | Same-second token refusal | Fix | with 9, same todo | sniewiif | open | |
|
||||
| 9 | Lockout keyed on `RemoteAddr` | Fix | [261022-vfz](../quick/261022-vfz-user-plugin-login-throttle-via-surf-clie/) · [todo](../todos/pending/2026-10-22-user-login-lockout-and-same-second-cutoff.md) | sniewiif | done (unreleased) | `b6f8055` → v0.5.0 |
|
||||
| 10 | Same-second token refusal | Fix | [261022-vfz](../quick/261022-vfz-user-plugin-login-throttle-via-surf-clie/) · [todo](../todos/pending/2026-10-22-user-login-lockout-and-same-second-cutoff.md) | sniewiif | done (unreleased) | `a484d0e` → v0.5.0 |
|
||||
|
||||
Status values: `open` · `done` · `declined`. Shipped: local commit now; replace with the v0.5.0 plugin/framework tags at release. Do not write a mid-wave plugin tag.
|
||||
|
||||
@@ -60,8 +60,8 @@ Suggested order if you care about risk: G4 (serve blacklist), then G3, G2, 9+10,
|
||||
- **G8.** Personal tokens die via `revoked_at`. `RevokeUserAccess` already sets that on deactivate/ban. Do not teach the API-token guard a JWT cutoff. Password reset killing API tokens would be a separate, explicit revoke.
|
||||
- **7.** Sociallogin already has `token_cookie` for OAuth. Password `/login` does not set a cookie. `--discuss` must decide cookie rotation on `/refresh` (G3 left the body-only rotate) and keep SameSite=Lax (no new CSRF token).
|
||||
- **8.** Plugin config; no framework wrap.
|
||||
- **9.** `/login` uses `RemoteAddr`; `/register` already uses `surf.ClientIP`.
|
||||
- **10.** `RevokeUserAccess` already truncates. Reset-password and the admin password set still stamp `time.Now()`.
|
||||
- **9.** Done locally (`b6f8055`). /login keys the throttle on surf.ClientIP with http.trusted_proxies (the /register expression); RemoteIP stays the RemoteAddr helper; without trusted proxies X-Forwarded-For is ignored.
|
||||
- **10.** Done locally (`a484d0e`). /reset-password and the admin password set truncate the cutoff to whole seconds like RevokeUserAccess; change-password and bouncer unchanged.
|
||||
|
||||
## Reply to send
|
||||
|
||||
@@ -101,9 +101,9 @@ TODO: ships in SummerCMS v0.5.0 — config key <name>.
|
||||
|
||||
Login lockout keyed on RemoteAddr
|
||||
Agreed. /login used RemoteAddr; /register already uses the trusted-proxy client address. Behind a reverse proxy five failures locked everyone.
|
||||
TODO: ships in SummerCMS v0.5.0 — /login throttle uses surf.ClientIP.
|
||||
Ships in SummerCMS v0.5.0 (sm-user-plugin b6f8055, tagged with that wave): /login counts failed logins per account and client address, and the client address is now the one /register and the user-api rate limit use: behind a proxy listed in http.trusted_proxies, the X-Forwarded-For client; otherwise the connection address. An X-Forwarded-For header from an address not in http.trusted_proxies is ignored, so it cannot dodge or move a lockout. List your nginx/Caddy address in http.trusted_proxies; without it every visitor still counts as the proxy.
|
||||
|
||||
Same-second token refusal
|
||||
Agreed. JWT iat is whole seconds; some tokens_valid_after writers stamped sub-second time. RevokeUserAccess already truncates. Reset-password and the admin password set will too.
|
||||
TODO: ships in SummerCMS v0.5.0 — a token minted in the same second as a reset is accepted.
|
||||
Ships in SummerCMS v0.5.0 (sm-user-plugin a484d0e, tagged with that wave): POST /reset-password and an administrator's password set on the Users form stamp tokens_valid_after with the current whole second, as deactivate and ban already do, so a token minted in the same second as the reset (the login right after it) is accepted and every token from an earlier second is still refused. As with deactivate and ban, a token issued earlier within that same second also stays valid, because iat has no finer resolution. /change-password and the guard's comparison are unchanged.
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user