Desktop: System-wide proxy not used when adding a new account to the client

[Volker-K]

Expected behaviour

When adding a new account, a browser-based window should open, request credentials and ask for authorizing this client to access this specific cloud account.

Actual behaviour

Timeout message
Access to existing accounts works fine.
After entering the proxy configuration manually in the desktop client, adding an account worked.

Steps to reproduce

1. Provide system-wide proxy settings (windows)
2. Start the desktop client, configure "use system-proxy"

3. Try to add a new account -> Timeout

4. Switch desktop client to manual proxy settings in it's network-section

5. Enter the name of the proxy
6. Try to add new account -> Success

Client configuration

2.5.0 build 20181112

Operating system:
Windows 10

OS language:
german

[Volker-K]

No change of behaviour in 2.5.1final build 20181204

[Volker-K]

Still happening in version 2.5.2. Client is sort of unusable for average users behind a proxy.

[Volker-K]

And 2.5.3: Still not solved. Even no triage.

[ozzi-]

I have the same issue, seeing there is no progress since nov 18 makes me slightly unconfortable

[brtptrs]

Have you tried the 2.6 RC version?

https://download.nextcloud.com/desktop/prereleases/Windows/

For me that seems to solve the proxy related problems.

[ozzi-]

2.6 RC does not fix this issue...

[Volker-K]

Same here. Configuration was deleted before installation of 2.6 RC, connect to any NC instance ended with a timeout.
"Use system proxy" is set in Network Settings,
I've entered our proxy manually -> it worked,
after establishing the account I've switched back to system proxy and synchronization worked.
So system proxy is used, but not while connecting to an account. Changing to a manually set proxy is a workaround and no solution.
btw: I didn't find the login via application token any more. Isn't it supported any longer?

[ozzi-]

2.3.3.84 doesn't work either. owncloud 2.5.4 it works. lol

[Volker-K]

I wished, 2.5.4 was stable...

[ozzi-]

ok I managed to fix this for my custom build, under src/libsync/configfile.cpp

```
int ConfigFile::proxyType() const
{
if (Theme::instance()->forceSystemNetworkProxy()) {
return QNetworkProxy::DefaultProxy;
}
if(getValue(QLatin1String(proxyTypeC)).toInt() == 0){
return 3; // patching
}
return getValue(QLatin1String(proxyTypeC)).toInt();
}

QString ConfigFile::proxyHostName() const
{
if(getValue(QLatin1String(proxyTypeC)).toInt() == 0){
return "myproxyhostname";
}
return getValue(QLatin1String(proxyHostC)).toString();
}

int ConfigFile::proxyPort() const
{
if(getValue(QLatin1String(proxyTypeC)).toInt() == 0){
return 8080;
}
return getValue(QLatin1String(proxyPortC)).toInt();
}
````

[Volker-K]

Official 2.6.0 got still the same error.

[Volker-K]

Happy anniversary!

[Volker-K]

Still no change in 2.6.2:

[ozzi-]

See you in a year @Volker-K :D

[Volker-K]

We will :-D https://github.com/ozzi-
I've built a dirty workaround with changing the ini-file during SCCM distribution. Works. At least today.

[Volker-K]

Still not fixed in 2.6.3.

[Volker-K]

Found out a possible reason for this issue. Accidentally...

Have a look at the manual (https://docs.nextcloud.com/desktop/2.6/)
Look out for Advanced Usage, Config File.
[proxy] section.

type, defaut (if nothing is set) is 2.
2 = no proxy used.

That's exactly what the new login flow does: Doesn't us a proxy because the default value is not set to any value, so we assume it's 2. I tried it on a blank system: The sync process acts incorrect by using a system proxy although "no proxy" is set.

So perhaps the sync process should be fixed instead and in a perfect world we would get commandline options to set a proxy address during an automatic setup?

Update: I've created a batch-file that adds the correct proxy setting to the config file when no proxy setting is found. It even first checks if only an old config file exists that will be migrated to the new location; in this case the old file ist altered.
As long as I understand the documentation right that is the way it should have been done all the time, even before the new login flow.

@ozzi-, @camilasan

[er-vin]

@misch7 isn't it fixed with your recent PRs ?

[Volker-K]

I'll try it tomorrow via RDP in my company. Got no windows in my homeoffice ;-)