Grey page - Waiting for page to render

Here is my setup, 2 virtual machines, 1 running nextcloud on 192.168.0.39 - https;//cloud,XXXXXX,net, 1 running collabora on 192.168.0.38 - https;//office,XXXXXX,net, following the guides to install docker and then collabora went smooth, I can see the xml if i go to https;//office,XXXXXX,net/hosting/discovery I get the wopi-discovery xml stuff. The major problem I see is when trying to open a document or spread sheet through nextcloud the page attempts to load and stays grey. looking at the console log of firefox it seams its trying to load 192.168.0.38 instead of https;//office,XXXXXX,net which is causing a cert issue I think due to coming from the ip instead of dns address. every browser/device I try weather it be inside my local network or from the outside ends up with same error.
Thanks for any assistance.

The log below is from firefox console log:

Waiting for page to render…
documents.js:295:5
:
core.js:3
Content Security Policy: The page’s settings blocked the loading of a resource at https;//192,168,0,38/loleaflet/c9a8aed/loleaflet.html?WOPISrc=https%3A%2F%2Fcloud,XXXXXX,net%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F512361_ocpsa06opxge&title=test.odt&lang=en&closebutton=1&revisionhistory=1 (“frame-src https;//office,XXXXXX,net”).

EDIT 1 - After alot more digging around, if I manually go to the link its trying to load instide nextcloud, i get the ui to load and it has a spinning circle saying initializing, so I know its working for the most part, just nextcloud is having problems?

Maybe your header settings in Nextcloud block the content from Collabora.

In Nextcloud what server address for Collabora did you enter, the IP address or the DNS name?

hm…this is a good suggestion, I will look into possible header setting changes, I have done what the install of nextcloud asks so you don’t have the advisory but that is it. I am using dns name in nextcloud for the address to collabora. Thank you. It seams like all services are fine but the interfacing between the 2 is the issue and I think you are onto something with the header stuff blocking the content. I don’t know much about headers but guess now is the time to understand more. I have also checked logs of both apache servers and nextcloud and all logs just have normal entries no errors and such.

EDIT
found some headway, how ever keeps going back to my original issue, for some reason its directing to my internal ip of 192.168.0.38 instead of keeping the dns, if i put in:

Header set Content-Security-Policy “frame-src cloud.XXXXXX.net office.XXXXXXX.net 192.168.0.38”

sure enough it passes the error and allows 192.168.0.38 to load, but the certs are not valid for the ip, only the office.XXXXXX.net. so it prompts the connection not secure, but if i manually accept the not secure it does load.

pretty confused on what is changing it from the dns to my internal ip. even if im outside of my network its still trying to direct to the internal ip insted of dns. maybe this is a routing issue of some sort now?

to add even more, if i can figure out how https://office.XXXXXX.net/hosting/discovery is generated I think we will be onto something. if i spam refresh the page sometimes i get my internal ip, sometimes i get the dns address as the list of items. if i could get this to always be my dns address I think that will help me move onto the next step. Thanks

So this issue is SOLVED!!!, once the headers were passing properly, it was not sticking to my dns and instead returning my internal ip, setting “server_name=office.XXXXXX.net” during the docker run command fixed this issue. I almost have this working properly how ever my router isnt liking wss but thats a whole different issue, Thanks for the help.

1 Like