Steps to reproduce
- Open the Nextcloud iOS app.
- Enter the server URL and start the normal login flow.
- Authenticate successfully with username/password.
- Grant access.
- The app returns to the initial screen asking for the server address instead of adding the account.
Expected behaviour
After authentication and granting access, the account should be added and the Nextcloud app should open normally.
Actual behaviour
The normal login flow initiated from the iOS app returns to the server-address screen.
Important comparison: QR-code login works
Using the QR code displayed by the Nextcloud web interface works on the same iPhone, with the same server and same account. Scanning the QR code still asks for username/password; after authentication, authorization completes and the iOS app opens correctly.
This suggests that the account credentials and server authentication are valid, and that the problem is specific to the Login Flow V2 initiated directly by the iOS app.
Server-side tests
Creating a Login Flow V2 manually works:
POST /index.php/login/v2 returns a valid poll.token, poll.endpoint, and login URL.
After completing the generated login URL in Safari, polling manually with the returned token succeeds with HTTP 200 and returns server, loginName, and appPassword.
Example (sensitive values removed):
{"server":"https://nextcloud.familyoneline.fr","loginName":"[redacted]","appPassword":"[redacted]"}
Reverse-proxy observations
During a failed login initiated from the iOS app, nginx/SWAG access logs show the browser-side grant flow completing, including:
GET /login/v2/grant?... 303
POST /login 303
GET /login/v2/grant?... 200
POST /login/v2/grant 200
However, during this failed flow we did not observe the expected iOS app POST /login/v2/poll request in the reverse-proxy access log.
The /login/v2/poll endpoint itself is reachable. A manual request with an invalid test token returns the expected application response, and a complete manually-created flow can be successfully polled.
CrowdSec was also disabled temporarily for testing and the behaviour did not change.
Environment
- iPhone / iOS 18.7
- Nextcloud iOS app (current App Store version at time of testing, 2026-08-28)
- Self-hosted Nextcloud
- nginx/SWAG reverse proxy
- Cloudflare in front of the reverse proxy
- MariaDB / Redis
Additional information
The key reproducible difference is:
- Login initiated by entering the server URL in the iOS app: fails and returns to server-address screen.
- Login initiated by scanning the QR code from the Nextcloud web interface: succeeds after username/password authentication and opens the app.
We can provide additional nginx/SWAG or Nextcloud logs and perform further tests if needed.
Steps to reproduce
Expected behaviour
After authentication and granting access, the account should be added and the Nextcloud app should open normally.
Actual behaviour
The normal login flow initiated from the iOS app returns to the server-address screen.
Important comparison: QR-code login works
Using the QR code displayed by the Nextcloud web interface works on the same iPhone, with the same server and same account. Scanning the QR code still asks for username/password; after authentication, authorization completes and the iOS app opens correctly.
This suggests that the account credentials and server authentication are valid, and that the problem is specific to the Login Flow V2 initiated directly by the iOS app.
Server-side tests
Creating a Login Flow V2 manually works:
POST /index.php/login/v2returns a validpoll.token,poll.endpoint, andloginURL.After completing the generated login URL in Safari, polling manually with the returned token succeeds with HTTP 200 and returns
server,loginName, andappPassword.Example (sensitive values removed):
{"server":"https://nextcloud.familyoneline.fr","loginName":"[redacted]","appPassword":"[redacted]"}Reverse-proxy observations
During a failed login initiated from the iOS app, nginx/SWAG access logs show the browser-side grant flow completing, including:
However, during this failed flow we did not observe the expected iOS app
POST /login/v2/pollrequest in the reverse-proxy access log.The
/login/v2/pollendpoint itself is reachable. A manual request with an invalid test token returns the expected application response, and a complete manually-created flow can be successfully polled.CrowdSec was also disabled temporarily for testing and the behaviour did not change.
Environment
Additional information
The key reproducible difference is:
We can provide additional nginx/SWAG or Nextcloud logs and perform further tests if needed.