gotp decodes the stored secret with strict base32 and panics when that fails,
so a 2FA secret saved through the settings API in lower case, grouped by
spaces, or not base32 at all turned every login and every attempt to turn 2FA
off into an HTTP 500. An empty secret had the opposite problem: the login
check accepted the code of an empty HMAC key, which anyone can compute.
VerifyWithSkew now normalizes the secret and verifies nothing for an empty or
non-base32 one, so secrets already stored in a display form work again.
Turning 2FA on through the settings update stores the normalized secret and
refuses one no authenticator could match.
A failed login keeps its username in the in-memory log buffer, the
limiter table and the notifier queue, and the route accepted any body
the global cap allowed. The login route now takes at most 16 KiB and
answers a username over 256 bytes with the generic failure before any
of those see it; the user setters refuse such a name too, so no stored
username can be one the login route turns away.
The first user is now created when the server starts, with a random
username and password printed once to its log (docker logs, the journal),
instead of a fixed pair seeded by InitDB. CLI calls that initialize the
database are often piped away, as the Docker entrypoint's port lookup is, so
only the server's own log reliably reaches the operator.
`x-ui setting -show` keeps reporting hasDefaultCredential: true until a user
exists, so install.sh still sets its own credentials on a fresh install.
Existing databases are not changed. Verified on a built binary: fresh
setting -show, install.sh-style credential set, first start, login and
restart. The PostgreSQL lane was not run locally; the change adds no query.
Aleksey Fedorov
MHSanaei