Commit Graph

2 Commits

Author SHA1 Message Date
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
2026-09-25 19:30:06 +00:00
Claude
724dada3f4
Brand Gitea's auth screens, and stop Salir overstating itself
Two halves of the same complaint: the journey into the members area does not
feel like one platform.

Members sign in to /comunidad/ through Gitea, so Gitea's sign-in form and
authorize dialog are part of everyone's journey, not just of anyone who opens a
repository. That is what the earlier "is Gitea only for admins?" question got
wrong. Unthemed they are two dark screens in the middle of a cream site.

Unlike Decap, Gitea supports being themed, so this needs no forking and nothing
a release can silently undo. The repository holds only the colour overrides;
scripts/gitea-theme.sh concatenates them onto the light theme it reads out of
the running container. Keeping somebody else's stylesheet in here would go
stale and turn every Gitea upgrade into a merge — the script is re-run instead,
which is one line in the upgrade notes. Getting a variable name wrong leaves a
corner grey rather than breaking a page, which is the failure mode worth having
when the names belong to someone else's project.

The logo is the site's wordmark, as live text in the same font stack rather than
traced to paths: the site loads no webfont at all, deliberately, so visitors
already see it in whatever sans-serif their machine substitutes. Paths would
render a Montserrat most people never see on the site itself.

Salir was the sharper problem. It cleared this session and the stored token, and
then said "Sesión cerrada" — while the Gitea session in the same browser stayed
open and Gitea still remembered the authorisation, so one click signed the next
person straight back in with no password. On a laptop shared around an
association, that button was lying.

It cannot be fixed from here. Gitea's logout has been POST-only since 1.11.2, so
a link cannot trigger it and a cross-site POST needs a CSRF token this app does
not have; prompt=login is undocumented in every released version of Gitea's
OAuth2 provider, and a security control should not rest on that. So the logout
page now says exactly what is closed and what is not, and links to the one place
that finishes it. Being honest about a limit beats a reassuring message that is
false.

Verified: 101 checks, two of them new — logout warns rather than redirecting,
and leaves no token the server could still act with. The theme itself is
visual and has to be looked at; docs/server-setup.md §12 says where.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn
2026-09-25 16:28:10 +00:00