Prompt users with stale terms_version to re-accept
The three pre-legal-disclaimer users (ullrich, pistazie, nelli) have
NULL terms_version, and any future Terms update would leave every
existing user in the same state. Close the loop now that we have
version storage by redirecting any logged-in user whose
users.terms_version doesn't match the currently-published
TERMS_VERSION to a dedicated acceptance page.
Changes:
- auth.server: new recordTermsAcceptance(userId, version) helper that
writes both terms_accepted_at and terms_version.
- root loader: if the session user has a stale or NULL terms_version,
throw redirect("/auth/accept-terms?returnTo=<pathname>") unless the
request is already on an allow-listed path
(/auth/accept-terms, /auth/logout, /legal/*) so Terms are reachable
and logout works.
- New route /auth/accept-terms (GET renders the prompt, POST records
acceptance and bounces to a sanitised returnTo). Same-origin check
on returnTo to avoid open-redirect abuse. Logout button is provided
as an escape hatch.
- i18n: new auth.reaccept.* keys for EN and DE.
- Spec: new Requirement + five scenarios (redirect, allow-list,
successful re-accept, missing consent, returnTo sanitisation).
No action on the three legacy users is required beyond what they'll
experience on their next visit — the gate takes care of it.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
18fc023cb6
commit
f16e80a2eb
7 changed files with 192 additions and 1 deletions
|
|
@ -32,3 +32,26 @@ The registration form SHALL require explicit acknowledgement of the Terms of Ser
|
|||
#### Scenario: Missing version rejected
|
||||
- **WHEN** a registration request arrives without a non-empty `termsVersion` field
|
||||
- **THEN** the server responds with HTTP 400 and does not create a user
|
||||
|
||||
### Requirement: Re-accept updated Terms on next visit
|
||||
Logged-in users whose stored `terms_version` does not match the currently-published version SHALL be prompted to accept the current Terms before accessing any non-allow-listed page.
|
||||
|
||||
#### Scenario: Stale version redirects to accept-terms page
|
||||
- **WHEN** a logged-in user whose `users.terms_version` is NULL or differs from the current `TERMS_VERSION` requests any page outside the allow-list (`/auth/accept-terms`, `/auth/logout`, `/legal/*`)
|
||||
- **THEN** the server redirects them to `/auth/accept-terms?returnTo=<original path>`
|
||||
|
||||
#### Scenario: Allow-list keeps Terms and logout reachable
|
||||
- **WHEN** the same user requests `/legal/terms`, `/legal/privacy`, `/legal/imprint`, `/auth/accept-terms`, or `/auth/logout`
|
||||
- **THEN** the request is served normally without being redirected
|
||||
|
||||
#### Scenario: Successful re-acceptance updates both fields
|
||||
- **WHEN** a user submits the acceptance form with the required checkbox ticked
|
||||
- **THEN** the server updates `users.terms_version` to the current version and `users.terms_accepted_at` to the current timestamp, then redirects to the `returnTo` path (or `/`)
|
||||
|
||||
#### Scenario: Re-acceptance rejects missing consent
|
||||
- **WHEN** the form is submitted without the checkbox ticked
|
||||
- **THEN** the server responds with HTTP 400 and does not update the user row
|
||||
|
||||
#### Scenario: returnTo is restricted to same-origin paths
|
||||
- **WHEN** a `returnTo` value is not a same-origin absolute path (missing leading `/`, or starting with `//`)
|
||||
- **THEN** the server redirects to `/` instead, preventing open-redirect abuse
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue