docker
docker copied to clipboard
nextcloud
Granting access to clients not working with HTTPS
When running nextcloud in the docker-compose setup documented here, adding my server to a nextcloud client (e.g. Ubuntu Desktop or Android) will not work. Reason seems to be that on the grant website, there is an HTTP form target, instead of HTTPS.
I could fix that in my installation by setting overwriteprotocol to "https" like this:
docker-compose exec -u www-data app php occ config:system:set overwriteprotocol --value="https"
Exactly this statement can be read everywhere. But it has no effect on my installation. All traffic is correctly routed through the proxy. And "overwriteprotocol" is set. Nevertheless, nextcloud will provide http:// URL's.
Sorry, mate. This fixed it for me and that is why I wanted to document it somewhere. What is your NC version?
Hey man, I understand. I used the current docker image, so version 18.0.3.
@cronoself I'm in the same situtation - Nextcloud just seems to ignore the setting 'overwriteprotocol' => 'https', in the config.php. Not sure though whether this is a Nextcloud, Nextcloud+Docker, Nextcloud+Docker+Nginx or just a configuration issue.
Most of my non-progress is in the forum.
I was able to fix it for me by removing the 'overwritecondaddr' => '^172\\.20\\.X\\.X$', line from the config.php. That seemed to clash with the 'overwriteprotocol' => 'https', line.
Since the proxy's IP is not fixed in Docker it was wrong anyway (you can assign it a fixed IP, but I didn't do that).
The way I was able to fix it, is by setting up a test instance using the same steps by which I set up my prod instance. Then I added the overwriteprotocol' => 'https there and checked that Nextcloud correctly got the https. Finallly I compared my prod's config.php with that of the fresh instance and one-by-one removed any values that prod had, but test didn't (and that seem likely to be related, e.g. the mail_xyz settings in prod are unlikely to be culprits).
Hi there 🙂 Any news on this subject?
I searched for solutions on GitHub and on the community forum and basically two solutions are always proposed:
- Set
overwriteprotocoltohttps, this works for most people - Unset
overwritecondaddrin addition to 1.
In my case (docker+traefik), overwritecondaddr is already not set and overwriteprotocol seems to be ignored. The Nextcloud client (on Linux, Android and Windows; I tested all of them because I have three different devices to sync) keeps on trying to connect which http instead of https.
On Android, I was able to bypass the issue by using an App password (with a QR code).
On Linux, I cound not use an app password, but I was able to hack the "Grant Access" page to bypass the issue (I detailed my hack there: https://help.nextcloud.com/t/cannot-grant-access/64566/43).
On Windows, as the client does not give access to the "login" page (instead I have this error message: The polling URL does not start with HTTPS despite the login URL started with HTTPS. Login will not be possible because this might be a security issue. Please contact your administrator), I cannot use the same hack as on Linux.
The only solution I found for Windows is to disable HTTPS redirection in Traefik and give to the client my server URL as http, authenticate, and then set up the redirection again. But now, the problem that I have is that the Windows client is not able to upload files. I guess the issue is that it does deal with the redirection well, because I disable HTTPS redirection, uploading files works. But disabling redirection is not an ideal solution.
So instead of finding hacks and partial fixes on the client side, I would like to find a definitive solution on the server side. Could someone give me some insights on why overwriteprotocol is not taken into account?
Some related issues and posts on the subject:
- https://github.com/nextcloud/server/issues/24871
- https://help.nextcloud.com/t/some-http-links-not-rewritten-to-https-despite-overwriteprotocol-https/74192
- https://help.nextcloud.com/t/cannot-grant-access/64566
- https://help.nextcloud.com/t/desktop-client-is-trying-to-use-http-instead-of-https/122288
After some more digging, I think that I managed to solve the issue by just... recreating the container 😅 I have been making manual updates inside the same container for several days, so it's possible I left a change somewhere which caused more issues. By recreating the container (docker-compose down and then up), and leaving overwriteprotocol to https, now it seems to work 🙂
If the issue comes back for some reason, I will make updates.
Just setup a new VM with Oracle and from there I installed a Nextcloud with Docker using this [1].
When trying to use the Nextcloud desktop client I got the "The polling URL does not start with HTTPS despite the login URL started with HTTPS. Login will not be possible because this might be a security issue. Please contact your administrator" message.
The first thing I did to understand what my instance was doing was to list all the parameters from my config with
docker exec -u www-data fpm_app_1 php occ config:list
I found this values of interest:
"overwriteprotocol": "http"
"overwrite.cli.url": "http:\/\/***REDACTED URL***"
"overwritecondaddr": ""
(Actually overwritecondaddr is unsetted, I just represented here for clarity.)
Reading from this [2] document I understood that overwritecondaddr should stay blank; And both overwriteprotocoland overwrite.cli.url should have https. So I made the chances with those commands:
docker exec -u www-data fpm_app_1 php occ config:system:set overwriteprotocol --value="https"
docker exec -u www-data fpm_app_1 php occ config:system:set overwrite.cli.url --value="https://***REDACTED URL***"
After this the Nextcloud desktop client was working correctly.
I would suggest to make this an environment parameter at the docker-compose.yml to have this applied to every new install using HTTPS.
[1] https://github.com/nextcloud/docker/tree/master/.examples/docker-compose/with-nginx-proxy/mariadb/fpm [2] https://docs.nextcloud.com/server/19/admin_manual/configuration_server/config_sample_php_parameters.html
Same issue here. If overwritecondaddr is set, then the overwriteprotocol setting is ignored. Thanks for pointing this out - I was already going mad... :D
