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

[Mort]

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]

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

Nextcloud Collabora integration

Nextcloud integrates functionality to edit office documents online (even collaborative - meaning multiple user can work on the same document at same time). This integration primarily happens with Collabora Online, but other integration using same protocol exist with OnlyOffice and Microsoft Online. As this forum primarily targets private users this article covers CODE (Collabora Online Development Edition) which is free self-hosted Collabora Online variant for testing and home use. The integrati…

[Mort]

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.