Wrong proxy url being detected if running behind a reverse proxy

[juliushaertl]

The proxy currently fails when Nextcloud is running behind a reverse proxy, since $_SERVER does not contain the user facing request url.

https://github.com/CollaboraOnline/richdocumentscode/blob/f4d82d0111d26ffbeaa56c3416813f8471fff2b8/proxy.php#L117-L121 https://github.com/CollaboraOnline/richdocumentscode/blob/f4d82d0111d26ffbeaa56c3416813f8471fff2b8/proxy.php#L155

I'm not entirely sure how to solve this properly. In Nextcloud we use HTTP_X_FORWARDED_PROTO and HTTP_X_FORWARDED_FOR but we also have dedicated config.php flags to override the protocol/host, but that would require you to somehow setup the server classes to access the config values, so that would have a performance impact again.

This is the logic we use to obtain the actual remote address/protocol: https://github.com/nextcloud/server/blob/cb057829f72c70e819f456edfadbb29d72dba832/lib/private/AppFramework/Http/Request.php#L685-L710 https://github.com/nextcloud/server/blob/cb057829f72c70e819f456edfadbb29d72dba832/lib/private/AppFramework/Http/Request.php#L643-L664

[s3ppo]

i have the same issue when using OVERWRITEPROTOCOL=https in nextcloud config.php

the guys from nextcloud sent me to here... https://github.com/nextcloud/server/issues/21513

[jlaunay]

I had the same problem forcing $proxyURL = "https://"; was working, I solved the problem adding fastcgi_param HTTPS on; in nginx.conf. Maybe It could help ?

location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|ocs-provider\/.+|ocm-provider\/.+|.+\/richdocumentscode\/proxy)\.php(?:$|\/) {
            fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
            set $path_info $fastcgi_path_info;
            try_files $fastcgi_script_name =404;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            fastcgi_param HTTPS on;

            # Avoid sending the security headers twice
            fastcgi_param modHeadersAvailable true;

            # Enable pretty urls
            fastcgi_param front_controller_active true;
            fastcgi_pass php-handler;
            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;
        }

[bananer]

I also have requests to proxy.php failing in a nextcloud docker installation running behind a https reverse proxy due to Content Security Policy.

Digging through the code brought me to https://github.com/nextcloud/richdocuments/blob/01ffcbed19edac099cab9a94bc3987da9fcd5f2d/lib/WOPI/DiscoveryManager.php#L67 where the url is read from a file called discovery.xml but I can't figure out where it is written.

Manually replacing http: with https: in that file located at /var/www/htmldata/appdata_ocbuka776eof/richdocuments/richdocuments/ inside the docker container worked around the problem.

php occ config:app:get richdocuments wopi_url shows the proper https url on a fresh build. However, when opening a collabora document for the first time, discovery.xml is generated with the wrong url.

Changing custom_apps/richdocumentscode/proxy.php to always build a https url fixes the path the next time workspace.xml is generated.

TLDR: No real solution

[mschoeffmann]

For me, adding the line SetEnv HTTPS on to .htaccess before installing/activating Collaboara apps in Nextcloud works.

Anyway, I'd highly appreciate a built-in solution for reverse-proxy installations.

[manrajsingh]

For me, adding the line SetEnv HTTPS on to .htaccess before installing/activating Collaboara apps in Nextcloud works.

Anyway, I'd highly appreciate a built-in solution for reverse-proxy installations.

This worked for me!

I had Collabora Online and Collabora Online - Built in Code Server already installed so I added SetEnv HTTPS on to .htaccess and then tested if Collabora worked, it did not. I then proceeded to uninstall and then re-install both Collabora Online and Collabora Online Built in Code Server from app store and everything worked!

[Exceltoi]

Hi, I tried the same today with NC 19.0.1, Collabora online 3.7.3 & Collabora Online - Built-in CODE Server 4.2.503 but even with the line SetEnv HTTPS on to .htaccess it doesn't work on my side.