Reauthentication keeps the old login name when the new app token uses an email #17922

Steps to reproduce

1. Configure an existing Nextcloud Android account using its username, for example alice.
2. Invalidate its app token, for example after an account lockout and subsequent re-enablement.
3. Reauthenticate the existing account through Login Flow v2, this time signing in to the web flow with the same account's email address, such as alice@example.com.
4. Complete 2FA and grant access, then return to the app.

Expected behaviour

The new app token and its accompanying login name should replace the previous credentials together. The app should then access the account without triggering further failed logins.

Actual behaviour

The login flow succeeds and the app receives the new token, but subsequent requests still use the existing account's alice login name. The server associates the new token with alice@example.com, rejects the mismatched pair with HTTP 401, and the app asks to log in again. With a maximum failed-login policy enabled, repeated requests can disable the account again.

For comparison, a fresh installation in GrapheneOS Private Space authenticated with the email address successfully uses it for subsequent requests. WebDAV folder listings returned HTTP 207. This supports a problem with reauthentication of an existing account rather than email login in general.

The original account was disabled after five failed attempts using a token the server no longer recognized. Automatic account lockout was temporarily disabled during the later reauthentication test, so the subsequent lockout is a potential consequence of the failed requests, not something observed during that test.

Environment

• Android 16, GrapheneOS, Pixel 8 Pro
• Nextcloud Android 35.0.1, F-Droid
• Nextcloud Server 34.0.5, database user backend, behind Traefik
• TOTP two-factor authentication enabled

Relevant logs

After the web grant, /login/v2/poll returned HTTP 200 and Android logged Successful access - time to save the account. Subsequent Android requests returned HTTP 401. Server log excerpt, with identifiers replaced:

{"message":"App token login name does not match","data":{"tokenLoginName":"alice@example.com","sessionLoginName":"alice","user":"alice"}}
{"message":"Login failed: 'alice'"}

The 35.0.1 updateAccountAuthentication() code appears to update the stored token on the existing Android account without updating its login name. This is a code-based hypothesis consistent with the logs, not yet an independently reproduced root cause. Related: #17707 and nextcloud/server#44164; those reports do not describe this exact reauthentication path.

As an Italian, I can confirm that a login loop like this tends to bring the Lord remarkably close, usually through vocabulary best left out of the logs.