Desktop: Desktop client authorization directs requests to http instead of https during first time configuration.

[balpert89]

Expected behaviour

The client is getting the accepted appToken and logs in successfully.

Actual behaviour

The client indefinitly polls for the token but receives a HTTP 400 Error.

Steps to reproduce

1. Install nextcloud server.
2. Have HTTPS-only on the webserver configured.
3. Install nextcloud-client.
4. Configure it with the endpoint, e.g. https://cloud.example.com
5. Browser page opens up, granting access does not work

Client configuration

Client version: 2.6.0

Operating system: Fedora 29

OS language: German

Qt version used by client package (Linux only, see also Settings dialog): na

Client package (From Nextcloud or distro) (Linux only): nextcloud-client-2.6.0-1.fc29.x86_64.rpm

Installation path of client:

Logs

[OCC::AbstractNetworkJob::start     OCC::SimpleNetworkJob created for "https://cloud.example.com" + "" "OCC::Account"
[OCC::AccessManager::createRequest  4 "" "http://cloud.example.com/login/v2/poll" has X-Request-ID "2bf61995-e24b-4c72-afa5-34ec6e15cc12"
[OCC::AbstractNetworkJob::start     OCC::SimpleNetworkJob created for "https://cloud.example.com" + "" "OCC::Account"
[OCC::AbstractNetworkJob::slotFinished  QNetworkReply::NetworkError(ProtocolInvalidOperationError) "Server hat \"400 Bad Request\" auf \"POST http://cloud.example.com/login/v2/poll\" geantwortet" QVariant(int, 400)
[OCC::AbstractNetworkJob::slotFinished  QNetworkReply::NetworkError(ProtocolInvalidOperationError) "Server hat \"400 Bad Request\" auf \"POST http://cloud.example.com/login/v2/poll\" geantwortet" QVariant(int, 400)

Here is the problem: The polling is directed to http instead of the protocol scheme configured in the dialog (https in my case). This creates two issues:

1. The "grant access" submit button on the web page for login flow v2 has http for the submit endpoint (which is rejected by the webserver). Inspecting the html element (redacted tokens):

<form method="POST" action="http://cloud.example.com/login/v2/grant">
    <input type="hidden" name="requesttoken" value="...=:...=">
    <input type="hidden" name="stateToken" value="..."> 
    <div id="submit-wrapper">
        <input type="submit" id="submit" class="login primary" title="" value="Zugriff gewähren">
        <div class="submit-icon icon-confirm-white"></div>
    </div>  
</form>

1. The polling does not work because it receives an http 400 error:

QNetworkReply::NetworkError(ProtocolInvalidOperationError) "Server hat \"400 Bad Request\" auf \"POST http://cloud.example.com/login/v2/poll\" geantwortet" QVariant(int, 400)

[Semirben]

I had the same error and fixed it by setting
"overwriteprotocol" => "https"
in my Nextcloud server configuration (/var/www/nextcloud/config/config.php)

You can check if the link for the Sync Clients says "http://" under "Settings -> Mobile & Desktop -> Server address". In my setup is showed "http://cloud.mydomain.com/nextcloud/" as my webserver has ports 80 and 443 open and the auto detection of the protocol only used the http port.
After setting the value in the config file and restarting the server, I was able to grant the access through the web browser

[balpert89]

Solved it, many thanks :-)

[setevoy2]

Thanks, it works, saved my evening.

[j1lgs0n]

I had the same error and fixed it by setting
"overwriteprotocol" => "https"
in my Nextcloud server configuration (/var/www/nextcloud/config/config.php)

One should also check if he/she/else has set one of the following config items in config.php as they seem to conflict with "overwriteprotocol":
'trusted_proxies','overwritehost','overwritewebroot','overwritecondaddr'

I played around with those config items and it just wouldn't start working. Once I removed all of them leaving only the 'overwriteprotocol' it finally was working. I am using the docker nextcloud setup with nginx proxy and the docker-letsencrypt-nginx-proxy-companion

[sday]

Surprised this isn't fixed yet. I had to actually add the line as it didn't exist at all, but it did fix my problem with both the Mac client and iOS client initial authorization. Also, being new to NextCloud I had to do a little searching to even find the config file. I tried NextCloud as one of the listed extra packages during a fresh install of Ubuntu 20 server.
sudo nano /var/snap/nextcloud/current/nextcloud/config/config.php
added the line as mentioned initially by @Semirben
"overwriteprotocol" => "https"

Also, my setup involves http redirected to https by the proxy server. There is no public http access to the server hosting my NextCloud install.

[QEDeD]

If you have this issue but are running Nextcloud in Docker, this is what you need to do. In my case, the nextcloud:fpm-alpine image is used.

1) Get into the running container that's based on the Nextcloud image

Use docker ps to get the name of the existing container, in this example the name is nextcloud-app.

Use the command docker exec -it <container name> /bin/ash to get a bash shell in the container:

docker exec -it nextcloud-app /bin/ash - note that it's /ash because we're dealing with an Alpine-based image/container

2) Find config.php
It should be in /var/www/html/config

3) insert 'overwriteprotocol' => 'https' into config.php
nano wasn't available, so I used vi config.php (check https://www.keycdn.com/blog/vim-commands if you aren't used to vim), and added 'overwriteprotocol' => 'https' so it looked like this:

  'installed' => true,
  'overwriteprotocol' => 'https',
  'twofactor_enforced' => 'true',

[jayagami]

I had the same error and fixed it by setting
"overwriteprotocol" => "https"
in my Nextcloud server configuration (/var/www/nextcloud/config/config.php)

You can check if the link for the Sync Clients says "http://" under "Settings -> Mobile & Desktop -> Server address". In my setup is showed "http://cloud.mydomain.com/nextcloud/" as my webserver has ports 80 and 443 open and the auto detection of the protocol only used the http port.
After setting the value in the config file and restarting the server, I was able to grant the access through the web browser

Thanks for your answer.
But I find this setting may affect local area Http visit.