Skip to content

Proxy credentials saved but never applied to network requests (regression, possibly related to #7996) #10738

Description

@animulavagula

⚠️ Before submitting, please verify the following: ⚠️

Bug description

The Nextcloud Desktop client accepts and saves proxy authentication credentials (username/password) via Settings → Network — the log confirms "Saved proxy password to keychain" — but the credentials are never actually applied to outgoing network requests. Every single request to the Nextcloud server (index.php/204, status.php, PROPFIND/LSCOL calls, etc.) fails immediately and indefinitely with QNetworkReply::ProxyAuthenticationRequiredError / "Proxy requires authentication", even right after the credentials were saved. The account remains permanently disconnected ("Errore di rete"), with the connection retry counter increasing indefinitely (retry count 1, 2, 3... 8 observed over ~25 minutes) and no successful request ever completing.

This may be related to #7996 (closed via #7999), which addressed a crash on entering proxy credentials — but the underlying issue of credentials not being honored at the network layer appears to persist as a related but distinct regression, since version 3.13.4 handles the same proxy configuration correctly.

Steps to reproduce

  1. Install Nextcloud Desktop (regression confirmed present in 34.0.3).
  2. Go to Settings → Network.
  3. Configure an HTTP proxy that requires authentication (proxy type: manual HTTP, port 80).
  4. Enter the proxy username and password and save.
  5. Log confirms: "Saved proxy password to keychain".
  6. Despite this, every subsequent network request to the Nextcloud server fails with:
    "Network request error "Proxy requires authentication" HTTP status 0"
    "QNetworkReply::ProxyAuthenticationRequiredError"
  7. The account stays in "Errore di rete" / disconnected state indefinitely; connection retry count increases on every retry cycle (observed reaching 8 within ~25 minutes) with no successful connection.

Note: this does NOT reproduce on version 3.13.4 with the identical proxy configuration — the same credentials authenticate successfully there.

Expected behavior

Once the proxy credentials are saved (as confirmed by "Saved proxy password to keychain" in the log), the client should apply them to all outgoing network requests via the Proxy-Authorization header, allowing the connection to the Nextcloud server to succeed — as it does on version 3.13.4 with the identical proxy configuration. The client should not remain permanently stuck in ProxyAuthenticationRequiredError after credentials have been explicitly provided and saved.

Which files are affected by this bug

Based on the log trace, the relevant files appear to be: - src/libsync/accessmanager.cpp — issues the network requests that consistently fail with ProxyAuthenticationRequiredError - src/libsync/clientproxy.cpp — sets the QNAM proxy configuration ("Setting QNAM proxy to be system proxy...") - src/gui/connectionvalidator.cpp — reports the proxy authentication failures on every connectivity check - src/gui/accountmanager.cpp — handles saving/reading the proxy password to/from the keychain (confirmed working: "Saved proxy password to keychain", "Read proxy password to keychain") - src/gui/creds/webflowcredentials.cpp — surfaces the ProxyAuthenticationRequiredError on every request The credential storage layer (accountmanager.cpp) appears to work correctly; the disconnect seems to be between the stored credentials and how/whether they're attached to requests made through accessmanager.cpp — possibly a QNetworkAccessManager proxy authentication handler not being (re)connected after credentials are saved.

Operating system

Windows

Which version of the operating system you are running.

Windows 11

Installation method

Official Windows MSI

Nextcloud Server version

34.0.3

Nextcloud Desktop Client version

34.0.3

Did this occur after an update or on a clean installation?

Clean desktop client installation

Are you using the Nextcloud Server Encryption module?

No

Are you using an external user-backend?

  • Default internal user-backend
  • LDAP or Active Directory
  • SSO - SAML
  • Other

Nextcloud Server logs

N/A — checked via `occ log:tail` while attempting to reproduce the crash; no relevant entries appear at the time of the crash. The only entries present are unrelated recurring PHP warnings from EventSource.php (header already sent), unconnected to the proxy authentication issue. This confirms the crash occurs entirely client-side, before any request reaches the server.

Additional info

next_log.txt

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions