Fix login flow by avoiding manual redirect policy on macOS client

[KarstenH792]

Summary

Fix login flow by changing redirect handling from ManualRedirectPolicy to NoLessSafeRedirectPolicy in src/libsync/accessmanager.cpp.

Problem

The current desktop client fails during account setup/login with a redirect-related error, while:

• server endpoints respond correctly
• curl tests succeed
• Nextcloud Desktop 4.0.2 works
• current versions fail

Fix

Replace:
QNetworkRequest::ManualRedirectPolicy

with:
QNetworkRequest::NoLessSafeRedirectPolicy

Result

With this change:

• Login Flow v2 completes successfully
• app password is returned
• DAV access works
• account setup succeeds

Additional context

This appears to be a regression compared to 4.0.2.

Related issue

Fixes #9794

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[KarstenH792]

Just checking if someone could take a quick look at this. The fix has been tested locally and resolves the login issue for me.

Happy to adjust if needed.

[KarstenH792]

Just checking in again on this PR.

I checked the current official v33.0.5 source, and the relevant code path still uses QNetworkRequest::ManualRedirectPolicy in src/libsync/accessmanager.cpp, so this issue does not appear to have been fixed elsewhere.

The proposed change is still minimal: switching this request policy to QNetworkRequest::NoLessSafeRedirectPolicy.

In my local testing, this resolves the login/setup failure while keeping the rest of the client behavior unchanged:

• Login Flow v2 completes
• app password is returned
• DAV PROPFIND succeeds
• account setup completes

I would appreciate a quick indication whether this approach is acceptable, or whether maintainers would prefer a different fix.

[KarstenH792]

@nilsding sorry to ping directly, but you seem to be the author of the recent accessmanager.cpp redirect handling changes, so you may be the best person to sanity-check this.

I checked v33.0.5 and the relevant code path still uses QNetworkRequest::ManualRedirectPolicy, so the proposed change does not appear to have landed through another fix.

I have a reproducible macOS setup where:

• Nextcloud Desktop 4.0.2 works
• newer clients fail during login/setup
• server endpoints behave correctly
• changing this one line to QNetworkRequest::NoLessSafeRedirectPolicy fixes the issue locally

Could you advise whether this approach is acceptable, or whether you would prefer a different fix to preserve the intent of the manual redirect handling?

[mgallien]

@KarstenH792 do you have logs that could explain what is happening differently ?
sorry for the delay
we did not ignore it but rather think that the manual redirect should be fixed to work as expected
we did revert the use of Qt Network redirect for a reason (solving issues for users)

[KarstenH792]

Hi @mgallien, thanks for looking into this, and sorry for the delay in getting back to you, but I didn't had time before the weekend to reproduce the logs.

I reproduced the issue with v33.0.5 and captured logs, but I would prefer not to attach the full logs publicly because they contain too much personal/server-specific information.

Relevant redacted extract from v33.0.5:

Fetched credentials for "https://nextcloud.mydomain.net" attempting to connect
Checking server and authentication
2 "" "https://nextcloud.mydomain.net/index.php/204" has X-Request-ID "<request-id>"
OCC::CheckRedirectCostFreeUrlJob created for "https://nextcloud.mydomain.net" + "status.php" "OCC::ConnectionValidator"
request finished QUrl("https://nextcloud.mydomain.net/index.php/204") with request id "<request-id>"
Redirecting cost-free URL QUrl("https://nextcloud.mydomain.net/index.php/204") to QUrl("https://nextcloud.mydomain.net/204")
AccountState connection status change: OCC::ConnectionValidator::Undefined -> OCC::ConnectionValidator::StatusRedirect
AccountState state change: "Disconnected" -> "Redirect detected"
Sending File Provider socket message: "ACCOUNT_NOT_AUTHENTICATED"
Network job OCC::CheckRedirectCostFreeUrlJob finished for "status.php"

For comparison, relevant redacted extract from the working 4.0.2 client on the same machine/server/network path:

Fetched credentials for "https://nextcloud.mydomain.net" attempting to connect
Checking server and authentication
2 "" "https://nextcloud.mydomain.net/index.php/204" has X-Request-ID "<request-id>"
OCC::CheckRedirectCostFreeUrlJob created for "https://nextcloud.mydomain.net" + "status.php" "OCC::ConnectionValidator"
request finished QUrl("https://nextcloud.mydomain.net/index.php/204") with request id "<request-id>"
2 "" "https://nextcloud.mydomain.net/status.php" has X-Request-ID "<request-id>"
OCC::CheckServerJob created for "https://nextcloud.mydomain.net" + "status.php" "OCC::ConnectionValidator"
Network job OCC::CheckRedirectCostFreeUrlJob finished for "status.php"
request finished QUrl("https://nextcloud.mydomain.net/status.php") with request id "<request-id>"
status.php returns: QJsonDocument({... "installed":true, "maintenance":false, "versionstring":"33.0.2"}) QNetworkReply::NoError
# Check whether authenticated propfind works.
6 "PROPFIND" "https://nextcloud.mydomain.net/remote.php/dav/files/<userid>/" has X-Request-ID "<request-id>"
PROPFIND of QUrl("https://nextcloud.mydomain.net/remote.php/dav/files/<userid>/") FINISHED WITH STATUS "OK"
AccountState connection status change: OCC::ConnectionValidator::Undefined -> OCC::ConnectionValidator::Connected
Sending File Provider socket message: ACCOUNT_DETAILS:****

So the behavioural difference appears to be:

4.0.2:
  /index.php/204 check finishes
  status.php is requested
  status.php returns QNetworkReply::NoError
  authenticated PROPFIND succeeds
  account becomes Connected

33.0.5:
  /index.php/204 redirects to /204
  this is treated as StatusRedirect
  account changes to "Redirect detected"
  file provider is marked ACCOUNT_NOT_AUTHENTICATED

This was after upgrading an existing working 4.0.2 setup to 33.0.5. The account still existed in the client. After the upgrade the client asked me to log in again; after granting access in the browser, the client remained offline.