Docker: ENV or config.php way to redirect HTTP to HTTPS

Created on 30 Jan 2019  路  14Comments  路  Source: nextcloud/docker

Is there a way to automatically set up the apache container to redirect http to https?
Thanks

question

Most helpful comment

@gregn610 set

  'overwriteprotocol' => 'https',

in your config/config.php

All 14 comments

Sure!
https://hub.docker.com/_/php#changing-documentroot-or-other-apache-configuration

@gregn610 set

  'overwriteprotocol' => 'https',

in your config/config.php

Overwrite protocol will not solve all problems. I will create a PR for Apache running on SSL (probably this week). In short: you need to create a virtualhost with SSL in etc/apache2/sites-enabled and set a redirect in the existing virtualhost on port 80. All SSL related issues will disappear.

Sent from MailDroid

-----Original Message-----
From: Markus Bergholz notifications@github.com
To: nextcloud/docker docker@noreply.github.com
Cc: Subscribed subscribed@noreply.github.com
Sent: ma, 04 feb. 2019 18:35
Subject: Re: [nextcloud/docker] ENV or config.php way to redirect HTTP to HTTPS (#628)

@gregn610 set

  'overwriteprotocol' => 'https',

in your config/config.php

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/nextcloud/docker/issues/628#issuecomment-460339222

I seem to have a similar problem using any version (fpm,fpm-apine,apache).
The app works behind a proxy(jwilder+letsencrypt-companion) but the links for webdav and sharing links show only http because the proxy link is done via port 80(my guess)

will this solution fix the issue?

Yes. The problem is that the connection between the proxy and Nextcloud is not encrypted (http). Nextcloud needs an encrypted connection, even if it is behind a SSL terminating proxy. I created a new virtualhost on 443 and it is working like a charm. Now I only need to get the PR working and get the feedback of the guys who can merge the request. Behind a proxy it is also recommended to add a trusted proxy entry in config.php so you will see the real IP addresses of the users.

Could that be done via ENV as well?
something like:
TRUSTEDPROXY=proxy_host or TRUSTEDPROXY=172.17.x.x

the problem of adding stuff to a config file after depolyment, or binding a config(-v /path/to/modifiedconfig.php:~/config/config.php) is not really that scalable in terms of automation...

Yes, the first PR for the HTTPS is almost ready now, see #644. After that I will create another one for the trusted proxy. I already tested it in my own environment, I only have to create the PR as a next step.

can a trusted proxy also be a fqdn instead of an ip?

can a trusted proxy also be a fqdn instead of an ip?

I have no idea, I only saw the IP's in the examples upstream but perhaps FQDN's will work when DNS is setup correctly. You are more than welcome to test this as soon as the PR is out. If you want to test it now, you have to add the trusted-proxy entry to your config.php, see
(https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/config_sample_php_parameters.html?highlight=trusted%20proxy#all-other-configuration-options)

I've tested it and it works with a correct fqdn (I get no error message). but it works also when I remove the trusted proxy. For me it is sufficient when I set 'overwriteprotocol' => 'https',.

But the case is when nextcloud is runnung inside docker swarm mode, where the reverse proxy has no fixed ips or several ips. Or when it is deployed behind an aws loadbalancer. It has three rotating A/AAAA records.

I looked at 2 ways of solving this: you can solve a few strange behaviours by applying some patches (overwriteprotocol, .htaccess, adapt proxy settings) or enable SSL. For me the SSL way seems the better way because you stay close to the upstream image which more or less expect to run with SSL enabled, and several auto configuration options were set correctly with SSL in place. I will test the PR with Traefik myself and I will try both the IP's and the name.

Do you have the real IP addresses of the requests in your logfiles or the IP's of the proxies? That was the main advantage of the trusted proxy setting I could find, service discovery works when SSL is enabled (or patched with overwriteprotocol).

can a trusted proxy also be a fqdn instead of an ip?

I have no idea, I only saw the IP's in the examples upstream but perhaps FQDN's will work when DNS is setup correctly. You are more than welcome to test this as soon as the PR is out. If you want to test it now, you have to add the trusted-proxy entry to your config.php, see
(https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/config_sample_php_parameters.html?highlight=trusted%20proxy#all-other-configuration-options)

I think docker containers will accept the container name as upstream hosts... if you look at the "full" dockerfiles that rely on supervisord configs the containername "app" is used for upstream host.

Could that be done via ENV as well?
something like:
TRUSTEDPROXY=proxy_host or TRUSTEDPROXY=172.17.x.x

the problem of adding stuff to a config file after depolyment, or binding a config(-v /path/to/modifiedconfig.php:~/config/config.php) is not really that scalable in terms of automation...

Have a look here, this should help https://github.com/nextcloud/server/pull/3966

https://github.com/nextcloud/docker#using-the-apache-image-behind-a-reverse-proxy-and-auto-configure-server-host-and-protocol

Was this page helpful?
0 / 5 - 0 ratings