Build-in Collabora not working (because of reverse proxy?)

Mort · January 3, 2023, 8:19am

Hi,

I installed Nextcloud and the required apps (Nextcloude Office + Built-in CODE Server (ARM64)) on a new RasPi 4 with the latest 64bit Pi OS and PHP 8.1 (from external repository).

Since I also use some other web apps I don’t want to move yet, the “public” server (i.e. with port forwarding in the router) currently is an older RasPi forwarding the nextcloud subdomain to the new one via Apache (ProxyPass etc.), also handling SSL via LetsEncrypt while the “Nextcloud Pi” is http only (with trusted_proxies and overwrite… settings in config.php).

In the Nextcloud Office settings, the server is shown as reachable, but if I try to add a document or “edit locally”, I see kind of a progress bar on top, and then nothing happens. In the browser’s console I see either “Launched external handler for 'nc://open/@/Test.odt?token=…” (Chrome) or a warning “Prevented navigation to “nc://open/@/Test.odt?token=…” due to an unknown protocol.” (Firefox). This happens even if I select a Collabora test server (I tried the ones in Sweden and Ireland).

If I click on the setting option to use the build-in server again, I get “Saved with error: Collabora Online should use the same protocol as the server installation.”

So, maybe I need some additional forwarding or proxy settings? But then, why doesn’t it work with test servers as well? And is there a way to avoid the warning in Firefox?

Also, (once it works), what should I put into the WOPI allow list? The external IPs (v4 and v6) aren’t fixed, can I just put the server name or the internal IP there?

wwe · January 3, 2023, 8:31am

please take a look at this article containing lot of information about CODE integration

Mort · January 3, 2023, 9:22am

Thanks, that’s at least a nice overview how it works with “usual” CODE servers. But I can’t do much of the troubleshooting steps with a test or the build-in server. For test servers, I’m simply missing permissions, and the build-in one seems to wrap everything via https://myserver/apps/richdocumentscode_arm64/proxy.php. There seems to be an “internal” coolwsd running on port 9983, but I don’t know if it’d be a good idea to mess about with it…

Since it doesn’t even work with test servers, I guess there’s some issue with the Collabora server reaching my Nextcloud server. DNS and port should be fine (after all, I can reach my Nextcloud from everywhere), but as the data probably isn’t the common http load, maybe I need some additional proxy settings?
Currently, it’s just

<VirtualHost *:80>
  ServerName ...

  RedirectPermanent / https://.../
</VirtualHost>

<VirtualHost *:443>
  ServerName ...

  SSLProxyEngine On

  ProxyPass / http://otherraspi/
  ProxyPassReverse / http://otherraspi/

  SSLCertificateFile /etc/letsencrypt/live/.../fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/.../privkey.pem
  Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

Or maybe Nextcloud ignores the “overwrite…” settings and passes the http address to the CODE server? Not sure how the RedirectPermanent would work out. The CODE server might not handle the 301 response…

I also wonder a bit about the nc://… - shouldn’t this be some https request according to the article?

Little update:
Removed ProxyHTMLEnable and encoding workaround, which has been a copy&paste remainder from a case where I needed URLMaps.
Also tried ProxyPass(Reverse) for port 80 instead of redirecting, but as Nextcloud itself also redirects, I’m not sure that has any effect.
If I use the build-in server, in the log I see “Fetched capabilities endpoint from …” working fine when trying to open a document, but no (logged) follow-up requests.

scheppi2610 · November 10, 2023, 10:32am

Hello I have a very similar problem.
I have drilled down that my WOPI call [getWopiUrl] https://host.tld/index.php/apps/richdocuments/wopi/files/97204_oct05x2wcj1n
calls the wrong url:
"http://host.tld/apps/richdocumentscode/proxy.php?req=/browser/5093121/cool.html?WOPISrc=https%3A%2F%2Fhost.tld%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F97204_oct05x2wcj1n&title=%2Ftest.docx&lang=de&closebutton=1&revisionhistory=1

i have no idea, how i can make WOPI to create a https url instead of http…

the reason is, that i do ssl offloading on my haproxy and internally conntect via http(80) to my nextcloud.

wwe · November 11, 2023, 5:48pm

there are many hints for built-in CODE as well, especially in some linked threads. you are welcome to adopt the WIKI for built-in CODE variant this would be great help.

built-in CODE completely relies on reverse proxy headers - config.php > overwrite* directive doesn’t apply there.

Nexctloud itself tells CODE where it lives. likely your reverse rpoxy settings are wrong ot incomplete - especially look at overwrite* settings.

scheppi2610 · November 12, 2023, 8:25am

Thank you @WWE-Corey for coming back to my issue. I think I do have all variables set accurately as long as they are needed:
‘trusted_domains’ =>
array (
0 => ‘#Server-IP#’,
1 => ‘server.mydomain.de’,
),
‘trusted_proxies’ =>
array (
0 => ‘#Proxy-IP#’,
),
‘overwriteprotocol’ => ‘https’,
‘overwritehost’ => ‘server.mydomain.de’,
‘overwrite.cli.url’ => ‘https://server.mydomain.de’,

I intentionally left out overwritewebroot and overwritecondaddr as i want to access my NC only via external address on standard webroot.

Is there a more detailed documentation for CODE built-in server where I can find what config / headers is needed to accurately set urls?

To remind you: My setup is like:

Client(extern) → FritzBox → (SSL-in) HAProxy (SSL-Offload) → (http in) NC (w/CODE built in) and my domain points to my Fritz-Box with Port-Forwarding (443) to my HAProxy. On the HAProxy letsencrypt SSL Cert stuff is done and all further requests got to backend via http and not https.

regards, Felix

P.S.: I added to my proxy config something like:
X-Forwarded-Proto: https
but this does not help either. Where can i find what headers built-in CODE server relies on?

P.P.S: all valid urls https://server.mydomain.de/hosting/discovery, https://server.mydomain.de/hosting/capabilities, https://server.mydomain.de/cool and https://server.mydomain.de/cool/adminwsare handled by NC with 404.

P.P.P.S:
coolwsd.log shows:
wsd-81327-81327 2023-10-10 07:31:57.433934 +0100 [ coolwsd ] INF SSL support: SSL is disabled.| wsd/COOLWSD.cpp:2486
wsd-81327-81327 2023-10-10 07:31:57.433944 +0100 [ coolwsd ] INF SSL support: termination is disabled.| wsd/COOLWSD.cpp:2487
wsd-81327-81327 2023-10-10 07:31:58.299641 +0100 [ coolwsd ] INF Remote configuration is not specified in coolwsd.xml| wsd/COOLWSD.cpp:1220

and in the end of the log:
wsd-81327-81335 2023-10-10 07:32:00.608756 +0100 [ websrv_poll ] WRN convert-to: Requesting address is denied: #my external IP ADDR#| wsd/COOLWSD.cpp:4010

scheppi2610 · November 12, 2023, 9:46am

ok, after many more tries CODE built-in server does now respond within NC !

I am not quite shure what finally made the trick, but here is MY config:

haproxy:
X-Forwarded-Proto: https

apache:
a2enmod headers

apache default.conf:
RequestHeader set X-Forwarded-SSL “1”
RequestHeader set X-Forwarded-Proto “https” env=HTTPS
roxyPreserveHost On
AllowEncodedSlashes NoDecode
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off
ProxyPass /browser https://127.0.0.1:9980/browser retry=0
ProxyPassReverse /browser https://127.0.0.1:9980/browser
ProxyPass /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
ProxyPassReverse /hosting/discovery https://127.0.0.1:9980/hosting/discovery
ProxyPassMatch “/cool/(.*)/ws$” wss://127.0.0.1:9980/cool/$1/ws nocanon
ProxyPass /cool/adminws wss://127.0.0.1:9980/cool/adminws
ProxyPass /cool https://127.0.0.1:9980/cool
ProxyPassReverse /cool https://127.0.0.1:9980/cool
ProxyPass /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities retry=0
ProxyPassReverse /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities

NC config.php
‘trusted_domains’ =>
array (
0 => ‘#Server-IP#’,
1 => ‘server.mydomain.de’,
),
‘trusted_proxies’ =>
array (
0 => ‘#Proxy-IP#’,
),
‘overwriteprotocol’ => ‘https’,
‘overwritehost’ => ‘server.mydomain.de’,
‘overwrite.cli.url’ => ‘https://server.mydomain.de’,

plus an empty allow list for WOPI requests…

coolwsd.log still warns me about:
WRN convert-to: Requesting address is denied: #my external IP ADDR#| wsd/COOLWSD.cpp:4010

but it works and i can work on my documents online.

wwe · November 12, 2023, 8:23pm

collabora-built-in lives at https://cloud.mydomain.tld/apps/richdocumentscode/proxy.php

@scheppi2610 you config looks more like stand-alone CODE… maybe this is the reason for issues?

I have no resource handy but I remember there was a thread here where adding reverse proxy X-FORWARDED* headers resolved issues for built-in CODE… turns out for some reason built-in CODE doesn’t respect NC "overwrite*" settings - likely it’s linked to the above WIKI.

In general I would recommend to run dedicated CODE instance if your setup allows (CODE docker container is very easy). This recommendation is based on experience - often it’s easier to find docs and troubleshoot dedicated installation rather an integrated one when you rely on some magic and maybe undocumented hacks.