nextcloud / nextcloud/desktop

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

Open
#10,738 0 comments 0 reactions 0 assignees View on GitHub
0. Needs triage bug os: :door: Windows
Dominant language
C++
Stars
3.9k
Forks
1k
Avg merge
1d 17h
Merged PRs (30d)
123

Description

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

- [x] This is a **bug**, not a question or a configuration issue.
- [x] This issue is **not** already reported on Github (I have searched for it).
- [x] Nextcloud Server and Desktop Client are **up to date**. See [Server Maintenance and Release Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) and [Desktop Releases](https://nextcloud.com/install/#install-clients) for supported versions.
- [x] I agree to follow Nextcloud's [Code of Conduct](https://nextcloud.com/contribute/code-of-conduct/)

### 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?

- [x] Default internal user-backend
- [ ] LDAP or Active Directory
- [ ] SSO - SAML
- [ ] Other

### Nextcloud Server logs

```shell
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](https://github.com/user-attachments/files/31828793/next_log.txt)

Contributor guide

Open the contributing guide

Research direction

Start with src/libsync/accessmanager.cpp and src/libsync/clientproxy.cpp, then compare how src/gui/accountmanager.cpp saves and reads proxy credentials. Trace the failing ProxyAuthenticationRequiredError through src/gui/connectionvalidator.cpp and src/gui/creds/webflowcredentials.cpp. Done means saved credentials are applied to authenticated proxy requests and the client connects successfully, matching the 3.13.4 behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
desktop, networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.