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

⚠️ 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

Nextcloud server with LDAP/AD user backend, internal username = UUID (ldapExpertUsernameAttr empty), users log in with their sAMAccountName.
Install Nextcloud Android 35.0.0 and log in via login flow with the sAMAccountName.
Use the app over a network that is not whitelisted for brute-force protection (e.g. mobile data) and open a few files.
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:

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

@tux-sourceish

@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.

@tobiasKaminsky

@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.

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.

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.

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.

@JohnBrodie

Thanks @JohnBrodie, that matches our pattern exactly.

@tobiasKaminsky this might be the easiest way to reproduce it: any Nextcloud instance where a user logs in with their email address (login name = email, user ID = something else). The token is issued for the login name, while the capabilities request (okhttp/5.5.0) apparently sends the user ID. No LDAP needed.

I'll still run the fresh-install test with the access log today as promised.

@tobiasKaminsky

@tobiasKaminsky here's the answer to your question about when the wrong ID is used:

Access log analysis of a controlled fresh-install test (server 34.0.4.1, app 35.0.0, mobile network), thanks to our hoster. This narrows it down considerably:

09:22:05–09:23:07 Login flow v2, all fine.
09:23:08 App starts working (Nextcloud-android/35.0.0): cloud/user, capabilities?format=json (HTTP/1.1, 200/304), PROPFINDs: all fine. The received-shares folder is even prefetched at 09:23:09 without errors.
09:23:50–09:24:42 App used in the root folder, several refreshes: zero okhttp requests.
09:24:46 User opens the folder containing received shares (owned by another user; the owner's avatar is fetched in the same second) → first okhttp/5.5.0 request to /ocs/v2.php/cloud/capabilities → 401.
Until 09:27:06 266 okhttp requests, all capabilities, all 401. They come in bursts (typically 10–11, sometimes ~20) every time a folder inside the received shares is displayed. Opening/downloading files does not trigger them.

Excerpt (IDs and names pseudonymised):

09:24:46 PROPFIND /remote.php/dav/files/<uid>/Shares/            207  Nextcloud-android/35.0.0
09:24:46 GET /index.php/core/preview?fileId=…                    200  Nextcloud-android/35.0.0
09:24:46 PROPFIND /remote.php/dav/files/<uid>/Shares/ProjectA/   207  Nextcloud-android/35.0.0
09:24:46 GET /ocs/v2.php/cloud/capabilities  HTTP/2.0            401  okhttp/5.5.0
09:24:46 PROPFIND /remote.php/dav/files/<uid>/Shares/ProjectA/   207  Nextcloud-android/35.0.0
09:24:46 GET /ocs/v2.php/cloud/capabilities  HTTP/2.0  (3x)      401  okhttp/5.5.0
09:24:46 GET /index.php/avatar/<share-owner>/512                 200  Nextcloud-android/35.0.0

The failing requests differ from the app's regular capabilities calls: HTTP/2, no ?format=json, default okhttp user agent. So it looks like a separate client that is invoked when rendering items of received shares, possibly once per list item.

This also corrects my earlier assumption that it starts right at login: in the earlier case the user presumably went straight into the shared folders.

@JohnBrodie could you check whether the failures in your case also start when you open folders that were shared with you?

@tux-sourceish

@tux-sourceish Hello,

Thank you for the report. Could you please try with this PR: #17742?

@alperozturk96

@alperozturk96 Tested the QA build (version 17742) on Hotwav Cyber 15, Android 13, server 34.0.4.1, LDAP user with UUID as internal UID, mobile network.

Browsed through several folders in the received shares (exactly where the failing requests occurred before): no more App token login name does not match entries, no okhttp 401s in the log. Looks fixed. Thank you very much for the quick fix!

@JohnBrodie

Similar to @JohnBrodie 's environment, I am a home user that recently ran into this issue. Running Nextcloud 34.0.4 with latest Nextcloud app from the android app store. Symptoms match what has already been described.

After side-loading the 35.0.1 RC1 release from this site, the problem appears to be resolved.

Navigation Menu

Repository navigation

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

⚠️ Before posting ⚠️

Steps to reproduce

Impact

Environment

Related

Expected behaviour

Actual behaviour

Android version

Device brand and model

Stock or custom OS?

Nextcloud android app version

Nextcloud server version

Using a reverse proxy?

Android logs

Server error logs

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

⚠️ Before posting ⚠️

Steps to reproduce

Impact

Environment

Related

Expected behaviour

Actual behaviour

Android version

Device brand and model

Stock or custom OS?

Nextcloud android app version

Nextcloud server version

Using a reverse proxy?

Android logs

Server error logs

Additional information

Activity

tobiasKaminsky commented on Sep 24, 2026

tux-sourceish commented on Sep 24, 2026

tobiasKaminsky commented on Sep 24, 2026

tux-sourceish commented on Sep 24, 2026

JohnBrodie commented on Sep 27, 2026

tux-sourceish commented on Sep 28, 2026

tux-sourceish commented on Sep 29, 2026

alperozturk96 commented on Sep 30, 2026

tux-sourceish commented on Sep 30, 2026

knight-of-ni commented on Oct 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions