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
e11016a8e9