b90cbd2a9f
6 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Claude
|
b90cbd2a9f
|
One front door: the members area owns its own logins
Three complaints, one cause. Logging out could not finish because the session belonged to another server, whose logout is POST-only and unreachable from here. "Ese usuario ya está en uso" for somebody absent from Miembros, because erase_member deleted our row and left the git account standing — two stores of users, one of them showing. And the hand-off to a differently-designed domain, with a Forgot password that could never work. All three followed from delegating identity, so it is no longer delegated. Members now sign in at /comunidad/login against a scrypt hash in our own database, via werkzeug.security, which arrives with Flask. They have no account on the git server at all, which makes the collision impossible rather than fixed. Logout is one click. This removes more than it adds: the OAuth round trip, the client registration, tokens.py with its refresh-before-expiry logic, the gitea_tokens table, and the logged-out page that existed to apologise for a logout that did not log you out. The editor keeps per-writer attribution without per-writer tokens: one CONTENT_TOKEN commits, and each commit names its author, which Gitea's contents API supports and a test now asserts. CONTENT_TOKEN falls back to GITEA_ADMIN_TOKEN so nothing breaks on deploy, but it only needs write access to one repository, while the admin token can modify every account on the instance — and now has no remaining job. The refusals are the interesting part. Unknown name, wrong password, suspended member and invited-but-never-arrived all answer identically, asserted by comparing the rendered bytes. The hash check runs against a decoy even when there is no such member, so an unknown name does not answer faster. Attempts are rate limited, counted inside SQLite for the reason invites.py documents. A NULL hash never matches anything. Migration 2 adds password_hash and drops the dead OAuth tokens. Everyone starts NULL, including the owner, so scripts/set-password.sh exists and was tested before this could ship: it prompts without echo, never takes the password as an argument where ps would show it, and refuses a short one or an unknown member. Rehearsed against a rebuilt copy of the server's database: starts, keeps the photo, drops the tokens table, serves a login form with no redirect, signs in, signs out, stays out. 223 tests. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn |
||
|
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
|
a79e04396b
|
Stop showing members the name of the software behind the login
A member signing in has no idea what Gitea is, and for anyone this platform is ever sold to it is a competitor's name on their login page. Fourteen strings named it — a button, a logout page, an account-creation notice and eleven error messages — plus Gitea's own sign-in and authorize screens, which every member passes through. Ours are reworded: "el servidor de cuentas" where the thing has to be referred to at all, and nothing where it did not. Gitea's own screens take APP_NAME plus the two footer switches, which are supported settings rather than a patched template. APP_NAME goes in app.ini's unnamed root section, spelled DEFAULT in the environment mapping, so the docs carry a command to confirm it landed — a key written to a section that does not exist is accepted in silence. Comments, docstrings, column names and env vars keep the real name. The code has to stay honest about what it talks to, none of it reaches a browser, and renaming gitea_login would mean a migration for nothing. Two guards added, since this is the kind of thing that creeps back one error message at a time: no template renders the word outside a Jinja comment, and no string literal outside a docstring contains it. Checked against the previous commit, where they catch the one message that had already been missed by hand. Licence: MIT, no attribution-in-UI clause, and we redistribute nothing — the official image runs unmodified with its own LICENSE intact. Gitea ships the "powered by" switch itself. Reasoning recorded in §12. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn |
||
|
Claude
|
e11016a8e9
|
Refuse before the form, not after the password
A member followed his invitation link, chose a password, typed it twice, pressed save, and was shown the name of an environment variable. The server knew from the first byte of that request that it could not save anything: without GITEA_ADMIN_TOKEN it cannot set a password in Gitea. It asked him to do the work anyway. Three places had the same shape, all now checked up front through a new gitea.admin_configured(), mirroring mail.configured(): - the invitation page answers 503 with an explanation and no password field, identically for a real and an invented token so it cannot be used to probe for live ones - /recuperar refuses instead of mailing a link to a page that could only apologise — and its deliberately identical answer would have hidden that from the admin as well as the member - the sign-in page stops offering recovery it cannot complete Also: a 404 from admin_set_password now names the real cause. A member added without "crear también su cuenta" has no Gitea account, so the password change is aimed at nothing, and "Gitea rechazó el cambio de contraseña (404)" blames Gitea for an account that was never made. deploy-board.sh warns about settings that are present but empty. The previous check looked for missing names, and GITEA_ADMIN_TOKEN= has a name — which is why the deploy that led to this said nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn |
||
|
Claude
|
ed6b568d60
|
Hand the mail settings to the container, and rebuild on deploy
Two silent failures sitting between Phase A and a working invitation. The compose file never passed MAIL_* through. Compose does not give a container the contents of .env — it only substitutes into the compose file — so the settings could be filled in correctly and read by nobody, with the app reporting mail as unconfigured and the values sitting right there on disk. test_deployment.py now fails the build whenever .env.example and docker-compose.yml drift apart, which is how this happened and how it would happen again. The app's code is baked into the image (COPY apps /srv/apps), so a pull followed by --force-recreate runs the old code and says nothing. Added scripts/deploy-board.sh: rebuild, sync the compose file, restart, print the log, and name any setting present in .env.example and missing from the live .env. It never touches .env itself. Also: "no mail server configured" is now told apart from "the mail server refused". They want different things done about them, and the first one sent an admin looking for an SMTP error that never existed. The new-member form says so before it is filled in rather than after. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn |
||
|
Claude
|
e95c732c6f
|
Let members get a password of their own
Until now an admin created an account, the password appeared once on screen,
and that was the only copy. Gitea's Forgot password answers "Account recovery
is disabled because no email is set up", because this server has never been
able to send mail. Every route a member had to a password of their own was
closed, which made the members area unusable by anyone not standing next to the
owner.
Now: the admin enters a username and an email, the server creates the Gitea
account with a random password nobody ever sees — the admin included — and the
member is emailed a link to a Viena Latina page where they choose their own.
The same mechanism gives "¿Olvidaste tu contraseña?" that works, replacing
Gitea's dead page. Nobody leaves the site for either, which is possible because
PATCH /admin/users/{username} accepts a password.
A link is enough to take an account, so it is treated as a credential: single
use, short-lived, stored only as a SHA-256, and invalidated when a newer one is
issued so an older email stops working. SHA-256 rather than a password hash
because these are 32 random bytes, not something a person chose — there is no
dictionary to slow down. Recovery answers identically for a known and an
unknown address, or the form becomes a way to enumerate members one address at
a time, and stops after three tries so it cannot be used to mail-bomb somebody
using this server's reputation.
Rejecting a password deliberately does not spend the token. A typo must not
lock somebody out of an account they have never reached.
If the mail fails the admin is shown the link instead. The account exists
either way, so the difference is between a delayed invitation and a person who
simply never gets in.
Found while testing: the rate limit did not work at all. created_at is written
by SQLite as "2026-09-25 15:00:00" and I compared it against Python's
"2026-09-25T15:00:00+00:00"; a space sorts before T, so every row looked older
than any threshold and the limit silently never fired. It is now compared
inside SQLite, where the format and the clock are the same one.
Also drops two tabs from the sign-in page: OpenID, which nobody here will use,
and Register, which contradicted DISABLE_REGISTRATION and invited people to try
something the server then refused.
Verified: 126 checks. Tokens are hashed at rest, work once, expire, die when
reissued, and are refused for a suspended member; a short password and a Gitea
rejection both leave the link usable; recovery is indistinguishable for known
and unknown addresses and stops at three; creating a member emails them and
shows no password; a failed send surfaces the link.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn
|