35.0.0: capabilities request (okhttp) sends user ID instead of login name → login failures and account lockouts for LDAP users

[tux-sourceish]

⚠️ Before posting ⚠️

• This is a bug, not a question or an enhancement.
• I've searched for similar issues and didn't find a duplicate.
• I've written a clear and descriptive title for this issue, not just "Bug" or "Crash".
• I agree to follow Nextcloud's Code of Conduct.

Steps to reproduce

1. Nextcloud server with LDAP/AD user backend, internal username = UUID (ldapExpertUsernameAttr empty), users log in with their sAMAccountName.
2. Install Nextcloud Android 35.0.0 and log in via login flow with the sAMAccountName.
3. Use the app over a network that is not whitelisted for brute-force protection (e.g. mobile data) and open a few files.
4. Watch nextcloud.log.

Impact

• The failed logins trigger brute-force throttling → TooManyRequests on WebDAV → the app becomes unusable on mobile networks.
• With password_policy (maximumLoginAttempts), accounts get disabled → HTTP 503 → the app shows "maintenance mode". Our hoster counted 137 automatic account deactivations across six accounts within ten days.
• Removing the account and setting it up from scratch does not help: a freshly issued token fails on the very first capabilities request.

Environment

• App: 35.0.0 (Google Play) fails; 34.1.1 (APK from GitHub releases) works
• Server: 34.0.4.1 (also reported with server 35.0.0)
• Devices:

Related

Server-side report with further details: nextcloud/server#64555

Expected behaviour

The capabilities request uses the login name (as the token was issued for it), like 34.1.1 does.

Actual behaviour

{"level":3,"url":"/ocs/v2.php/cloud/capabilities","message":"App token login name does not match","userAgent":"okhttp/5.5.0","version":"34.0.4.1","data":{"tokenLoginName":"jdoe","sessionLoginName":"AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE"}}

Android version

Android 16 and Android 13

Device brand and model

Samsung Galaxy Tab S9 FE+ 5G, Android 16, managed via Android Enterprise; the 34.1.1 comparison test was done on Hotwav Cyber 15, Android 13

Stock or custom OS?

Stock

Nextcloud android app version

• App: 35.0.0 (Google Play) fails; 34.1.1 (APK from GitHub releases) works

Nextcloud server version

• Server: 34.0.4.1 (also reported with server 35.0.0)

Using a reverse proxy?

No

Android logs

No response

Server error logs

Additional information

No response

[tobiasKaminsky]

@tux-sourceish from the other issue:
Nextcloud Android 35.0.0 (Play Store): okhttp/5.5.0 requests to /ocs/v2.php/cloud/capabilities send the UUID instead of the login name → App token login name does not match → Login failed → TooManyRequests / disabled account via password_policy.

When is this wrong uuid to capabilites happening?
Then I can check what is wrong.

[tux-sourceish]

@tobiasKaminsky thanks a lot for picking this up so quickly!

What we know from our logs so far:

• The failing requests start immediately after login: the first ones appear in the same second as the login flow completes, with a freshly issued token.
• During normal use they come in bursts (up to ~10 per second), especially when opening files. Browsing seems to work at first; the trouble starts once files are opened.
• They keep coming continuously while the app is in use: our hoster counted over 3,300 of these log entries since Sept 17 across our devices.

I'm out of office until Monday. Then I'll run a controlled test (one action per minute: cold start, folder navigation, pull-to-refresh, opening PDF/image, background/foreground, idle) and post exactly which actions trigger the failing requests.

Happy to test a debug/dev build as well if that helps.

[tobiasKaminsky]

send the UUID instead of the login name

I was more referring to this.
The weblogin flow is started by Android.
After login server sends login/username back.
This is then used for next server calls.

So it would be interesting to see from a new app installation when the user id is wrong.

[tux-sourceish]

Thanks, understood! Some data points that may help narrow it down:

• The server stores the correct login name in the token (tokenLoginName: jdoe), so the login flow hands back the correct login name.
• With a fresh login on 34.1.1 against the same server, everything works. So the server's login flow response should be fine.
• On 35.0.0 with a fresh installation, the first failing capabilities request appears in the same second as the login flow completes. At the same time, WebDAV works with the same token (the first file could be opened), so the app seems to use the correct login name there.
• The failing requests use the user agent okhttp/5.5.0 instead of the usual Nextcloud-android/…, which suggests a different code path.

So my guess is that the UUID (user ID, e.g. from /ocs/v2.php/cloud/user) ends up as the username in this one code path, while the login name is used everywhere else.

On Monday I'll do a fresh installation on one of the tablets and try to capture the complete request sequence from our hoster's access log (user agent + timestamps), so you can see exactly which request comes first with the wrong ID.

[JohnBrodie]

I think I just ran into the same issue. After updating the Android app, I ended up locked out of my account (due to the brute force settings). Same "burst" of failed auths when using the Nextcloud app. This is just a small, home-use install, nothing has recently changed other than auto-updating client app. It seems that the cause it that I log in with my email, but my user ID is a different value (not my email address). If there's info I can provide just let me know and I'll try to get it, but there's at least an easy repro case that doesn't involve LDAP, assuming it's the same bug.