e17d1e05c6
2 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Claude
|
ea17bf3273
|
Give Gitea a deploy path, and invitations a second chance
Two findings from one screenshot of a dead forgot-password page. The page is Gitea's own, and it will always say recovery is disabled: the SMTP details are the members area's, and Gitea is a different container with no mailer and no need for one. But every member reaches Gitea's sign-in form on the way in, and that form links to it — so the broken route is the one they find first. The theme now hides the link. Ours, which works, is /comunidad/recuperar. The footer on that page still advertised the software and its version, which proves the settings added days ago never reached the server. /srv/gitea/docker-compose.yml is a copy and nothing ever synced it: deploy-board.sh syncs the board's compose file, and the Gitea directory has been hand-made since setup. CORS, the theme, OpenID, the register button, the footer — committed, documented, never applied. The file stays valid and the container stays healthy, which is why nobody noticed. scripts/deploy-gitea.sh syncs it, restarts, and then reads the settings back out of the running container and prints them, because this session has lost three separate afternoons to settings that were accepted somewhere and read by nobody. Separately: an invitation was only ever issued when the app created the account. Make the account by hand, add the member with the box unticked, and no invitation exists and none can be made — which is exactly how somebody ended up with an account nobody knew the password to. Miembros now has "Enviar invitación" on any active member with an address, for that case and for a failed send, an expired link or a corrected address. Issuing a new token voids the old one, so a forwarded link stops working. Refused before a token is issued when there is no address, since otherwise a working invitation would be spent on one that cannot be delivered. 183 tests. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn |
||
|
Claude
|
6ac814475e
|
Add a members area: roles and an internal board
Everything on this site so far has been a file built from git. This is the first component that runs code to answer a request and the first whose data git does not hold, so the trade is stated in the README and the backup script is not optional. Roles are owner, admin and user. The owner is seeded once from BOARD_OWNER and cannot be seeded again, because otherwise editing a compose file would be a quieter way to take the top role than asking for it; ownership moves only by transfer, inside the app. There is exactly one owner and a partial unique index enforces it, so the invariant holds even when a handler is wrong. The owner is beyond suspension and demotion by everyone, themselves included. Only the owner makes admins; admins make users. Sign-in goes through Gitea as a confidential OAuth client — the opposite of Decap, which has to be public because it runs in the browser. The rule the whole thing rests on is that a Gitea account is not a membership: entry needs an active row in `members`, or every account on the instance is a member, starting with the translations bot. Admins can delete any post; nobody can edit anyone else's, admins included. Taking a post down is visible to its author. Quietly rewriting it is not, and an admin who could do that could leave a sentence attributed to someone who never wrote it. The plan said admins could do both; this is the one place the implementation departs from it. Markdown renders with raw HTML disabled, which is the entire XSS defence and the reason there is no sanitiser: the renderer emits only its own tags and escapes the rest. The CSP carries no 'unsafe-inline', which makes an inline onsubmit silently inert rather than broken, so the confirmation dialogs live in a static file and a test fails any template that grows an inline handler. GDPR is in scope rather than deferred: erasure removes the member row and moves their authorship to a tombstone so the conversations around them still read, and any member can download their own writing. Verified: 63 checks pass, covering the membership gate, every role predicate, a direct insert of a second owner being refused by the index, atomic ownership transfer, CSRF, an offsite login redirect, script tags rendering as text, soft deletes leaving both listings and exports, and the member screens rendering for each role. Smoke-tested live: headers, both static assets, and the bare /comunidad redirect that the Caddy matcher has to cover. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn |