Class ServerAuthenticator

The authenticator over the server's database users, PUSH-WIRE-CONTRACT.md sections 3.2 and 3.3: Authorization: Basic, decoded as UTF-8 and split at the first colon, checked by UserAuthentication.getUser(conn,userName,password), which compares the clear-text password against the stored hash and never accepts the hash itself.

One code for every failure. No header that can be used, an unknown user, a wrong password and a database that cannot answer are all 401 unauthenticated with the same message, so a caller cannot probe which user names exist; the database failure is also logged SEVERE.

The sources, in order (section 3.2): the credentials file and the users registered from Java, held by PushCredentials - a user found there is authenticated there and nowhere else, so a wrong password is 401 and never a fall-through - then the database users.

Privileges (section 4.3) are the union of what the user's enabled database groups grant: under the [groups] of the credentials file when one is in force, which replaces the built-in definitions of PUSH-CREDENTIALS.md section 6 entirely, else under those built-ins (PushPrivilege.builtIn(String, boolean)).

The development fallback (section 3.3, Ruling 5): a request with no Authorization acts as the database user "iiziRun Developer" when the server is in development mode, the request is NOT secure by the one rule of WSHelper.isSecure - so a port a reverse proxy secures never falls back - and the remote address is the loopback interface. A disabled development account is refused as a request without credentials is (credentials required), the stored reason logged WARNING (the owner's ruling D-1 of 2026-09-27). The fallback user has the privileges of its groups, like any other database user: a disabled group grants nothing, so with every group disabled it is authenticated with no privilege. The first fallback is logged.