I recently setup a new NextCloud 25 environment which i now also exposed to the internet thru a reverse proxy (nginx).
For clarity the reverse-proxy and the NextCloud instance (with built-in-CollaboraOnlineDevelopmentEdition) live in different containers/VMās. For that reason they also have different hostnames/FQDN.
Because of the reverse proxy I had to set the overwritehost field in the NextCloud config.php to the host-name/FQDN of the reverse proxy.
In NextCloud this all works just fine and dandy as the clients are always presented links referencing the reverse-proxy.
However when opening a document it fails to load.
A look in the browser dev tools (F12) and it shows that it is telling the browser to access https:///apps/richdocumentscode/proxy.php?status which results in a content security policy violation and thus is not loaded.
Manually correcting the URL to https:///apps/richdocumentscode/proxy.php?status results in the expected āokā message.
Now I have attempted to set the config in NextCloud Office to āuse your own serverā but that menu is smart enough to then simply revert it back to āuse built-in CODEā because that is what it is referring to.
Now to test a possible solution I created a second host-name that the reverse-proxy also proxies to the NextCloud instance. With a different host-name I was able to set the āuse your own serverā option. When testing the proxy status manually that worked as expected.
However when attempting to open a document it still fails for the same reason as before.
So somewhere in the office integration it is not aware of the overwritehost setting and passing the host-name of the NextCloud instance instead of the reverse-proxy.
Is there some override setting I missed?
How would this normally be setup?
I understand from the collabora online documentation that the client is expected to connect to the collabora online server directly (not sure how that works given the content security policy) however in the built-in-CODE server NextCloud provides some proxy capability in order for the client to see just one FQDN.
obviously I donāt want to expose any thing other than the reverse-proxy to the internet.
To test the integration I setup a local instance with no reverse proxy. There the NextCloud Office integration works just fine.
But is also doesnāt have to switch host-names. So my conclusion is that it is having an issue with the replacing of the host-name which is necessary for the use of the reverse-proxy.
That page sure is being referred to an awful lot. Yes I did not explicitly mention that I read that page. The post was getting rather long.
Perhaps not intended but the reply comes across as āI have the answer but I prefer you find out for yourself.ā.
Now of course I read the page again cause I am a dumdum It wouldnt be the first time i missed key information. I figure hey perhaps I can make the correct URL stick using the commands described.
That did the same as in the GUI though because the URL is basically the same. (it also shows use build-in-CODE server in the GUI)
Now I did find at least one instance in the page source where it refers to the instance host-name rather than the reverse-proxy host-name.
in https:///index.php/apps/richdocuments/index?fileId=895&requesttoken=&path=%2Ftest_doc.docx
there is
var richdocuments_urlsrc = āhttps:///apps/richdocumentscode/proxy.php?req=/browser/a4b9c74/cool.html?ā;
defined.
That one is apparently unaffected by setting the overwritehost value.
The richdocuments app appears to have an issue in it where it doesnāt follow the NextCloud overwritehost value.
For those unaware: You may not load content from another host than the one originally serving the request, doing so will make your browser freak out. (for good reasons though, keeps you safe)
hello @RoyWarps I donāt like your reaction. Donāt forget forum members spend their free time so support you to solve your problem. and the only way to know what you did and tried is what you post.
From my experience majority of the issues with Collabora/Nextcloud Office result from the wrong configuration and wrong understanding of how WOPI protocol works. This is described in detail within refereed post. Iām aware built-in code works somehow different as it runs in Nextcloud application content but I donāt use it so I have no idea and no motivation to analyze it furtherā¦ you are welcome to extend the wiki article with built-in specialties so it becomes more complete.
Well I got it to work.
āNot so sureā if this is the correct way so use this advice with caution.
I went back to my test instance where it did work and started implementing the config with the live instance as an example.
The content violation turned out not be be blocking the document page from loading but it does leak internal names to the world.
I did solve that issue in a rather hacky way.
I created an entry in the host file of the reverse-proxy with the same host-name as the one that points to the reverse-proxy itself (yes thatās rather shifty).
With this host-name spoof in place I could configure nginx to proxy the requests to the actual NextCould instance but using the host-name of the proxy in the request.
If you then remove the overwritehost entry (if you have one) from the NextCloud config.php it will use the host-name from the incoming request and suddenly richdocuments no longer uses the wrong host-name.
There is probably a less janky way of getting nginx to put a specific host-name in the request headers. The key here is to not rely on the overwritehost feature to fix your reverse-proxy host-name issue but rather to get NextCloud to use the host-name given in the http request.
Of course this is still a workaround the richdocuments app has a bug in it. Or this is by design as built-in-CODE is not meant for commercial use, so ommit reverse-proxy compatibility? (it was already reported some time ago but no fix) Though most home implementation would need a reverse-proxy because they only have one public IP.
Now on to what was actually blocking the document page from loading. In the NextCloud office config page you have a field āAllow list for WOPI requestsā I had that set to 127.0.0.1 obviously I should have added the IP of the reverse-proxy to that list as well. That resolved the issue.
In case it helps others, my issue was that the trusted_domains field in config.php had the wrong IP Address for my server. I added the IP address in there and the system then worked.