Repository navigation
Service discover doesn't work behind reverse proxy #577
Description
Hey guys,
I'm using NextCloud docker image behind a Traefik SSL-terminating reverse proxy. I found I was unable to use service discovery to configure CalDAV/CardDAV on my iOS device, because the 301 redirect served by https://MYHOST/.well-known/caldav is an http URL (http://MYHOST/remote.php/dav), since the container has no native HTTPS setup.
I've temporarily worked around this by changing the following in .htaccess:
RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
To:
RewriteRule ^\.well-known/carddav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
RewriteRule ^\.well-known/caldav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
But I imagine this is not an ideal fix, since .htaccess could be automatically updated during upgrades / app installs.
Can we have a config.php option, tied to the occ maintenance:update:htaccess process, which would automatically insert the necessary https elements to ensure service discovery works? Perhaps something like overwrite.redirect.url = https://MYHOST?
Notes:
- Issue cal|carddav not setup properly (.htaccess) #528 is related
- I've written a more detailed description of the fix here: https://geek-cookbook.funkypenguin.co.nz/recipes/nextcloud/#use-service-discovery
Thanks!
D
Activity
kesselb commentedon Dec 12, 2018
I guess you have to adjust some of these values? but i'm not sure if these are considered for the well-known redirect.
https://docs.nextcloud.com/server/15/admin_manual/configuration_server/reverse_proxy_configuration.html
J0WI commentedon Dec 12, 2018
I think this could be fixed by #527
kesselb commentedon Dec 12, 2018
I dont use traefik but if i would go for this solution. Let traefik return the right url sounds like a better way to do it.
nextcloud/server#11850 (comment) all credits to @pauvos
zroug commentedon Dec 15, 2018
#527 won't fix the issue. (Maybe it is a Nextcloud bug, that it doesn't?)
I think the correct way to fix the issue without a change to Nextcloud is to add these lines
inside of
<VirtualHost>in/etc/apache2/sites-available/000-default.conf.cloud.example.comis your host name andhttpsis your protocol.UseCanonicalName Ontells Apache to useServerNamefor rewrites.ServerAlias *is not strictly necessary, but it makes the intention clear, that this virtual host should accept all connections.This will work for all rewrites that Nextcloud adds in the future. One could make it configurable using the same variables used in #527.
SysEngDan commentedon Jan 29, 2019
The suggested fix by the OP worked for me. I'm running NC 15.02 container behind an Nginx reverse proxy.
marceljd commentedon Feb 9, 2019
See #644, it is possible to fix this with changes in the proxy settings, but running Nextcloud Apache on https is the better way.
zroug commentedon Feb 9, 2019
While #644 can solve the issue, it requires to use an additional layer of encryption in a perfectly trusted network. My solution #577 (comment) can tell Apache from where it is accessed on the public network, without the need to access it the same way on the internal network. This solution also doesn't require any changes to the proxy settings or Nextcloud itself.
marceljd commentedon Feb 9, 2019
@zroug I did not see your solution untill now. I am not an Apache expert, but your solution would mean that all traffic is still unencrypted behind a proxy or not (since the port used is still 80 and the Apache SSL engine is off)? I agree that adding the servername with the real (external) hostname does add some security. The best solution would be to give the proxy the certificates of the Apache instance and let Apache only accept the connections to the servername that should be set to the external address. Or do I miss something?
The second question I have: would it still be possible to access the server by IP address for users who only need intranet access and do not have internal DNS set up?
@J0WI @tilosp @SnowMB what do you think? I'd be happy to build this into the PR (#644 ) if everyone thinks that this will be the better solution (or perhaps use both and add the server-name as an environment variable?).
edit: though the internal network in Docker or Kubernetes is fairly trustable, someone could break out of another container and sniff around. I would not consider an internal network as perfectly trusted. Adding SSL for the internal traffic is not a bad thing to my opinion.
zroug commentedon Feb 9, 2019
Yes that would mean that Apache is still on port 80 and Nextcloud is still accessible from internal ips. It has only an effect on some links, like share links or the dav redirect. Therefore I suggest to integrate that with #527 because that would make it explicit that it is the behavior that you want.
I certainly think that #644 is a good thing and some additional security dosen't hurt, but it solves a different issue. Sometimes you want to solve this issue independently.
For example: Traefik still has some issues with self signed certificates. That can make it difficult to use self signed certificates. You suggested to set
insecureSkipVerify: truebut that would mean that not much security is added because the certificate is not validated and more importantly it means you also skip verification for backends where you want to verify the certificate.marceljd commentedon Feb 10, 2019
OK, thnx for the explanation. I do not think both use cases can be solved at once. Besides that it is impossible to solve several upstream issues like all different Traefik discussions about encrypting traffic to the backends. I am aware of those but in general I think it is good to stick to standardized solutions as much as possible for mainstream applications and patching on different locations often leads to other problems in the future.
Based on this discussion I think it would be wise to implement a second environment variable in #644 that handles the redirect from http to https. The main goal should be to let the client container generate certificates and run on SSL with a default self signed certificate, but redirection is a seperate decision to make, or should at least have an option to disable it. Activating SSL will solve most issues of the security checks but it has certain restrictions. If you do not want or cannot enable SSL, you do not set the environment variable and nothing will change.
For #527 and #577 the goal should be to patch the server for various issues without activating SSL for those who need it, but I think the general advice should be to activate SSL where possible and let Nextcloud do the configuration-magic it normally does.
SysEngDan commentedon Feb 10, 2019
I think the proper resolution is to treat this issue, #577, as an improvement to NextCloud for reverse proxy support. I believe that most instances where this is being used for a professional use, it is located behind a reverse proxy, whether that's Trafik or Nginx, and the protocol between Trafik and the Apache hosted container is HTTP.
ffried commentedon Mar 4, 2019
For those that have control over the reverse proxy (e.g. an apache 2), the following config lines can fix the issue inside the proxy (as a workaround):
GuyPaddock commentedon Mar 5, 2019
I just posted a comment about another option for those using NextCloud on NGinx (even if you are not using NGinx for the proxy): #527 (comment)
kesselb commentedon Mar 10, 2019
I prepared a pull request for the documentation. Could you share your solutions? nextcloud/documentation#1297
SnowMB commentedon May 28, 2019
Thanks @kesselb for pointing that out. #528 and #635 had the same problem.
cdauth commentedon Aug 27, 2024
Do I understand it right that this issue was not actually fixed, but a workaround has been added to the official documentation?
Would it be possible to fix the issue, or is that technically not possible? Possible fixes could be:
X-Forwarded-*headers right inside Apache rather than in PHP so that the htaccess rewrite rules use the right protocol (not sure if Apache can do that)OVERWRITE*environment variables