Collabora can not open federated file?

Hello,

im trying to open a file shared between two ferderated NCs with Collabora Online Development Edition. Im running two NC 18.0.3 with richdocuments 3.5.1. Both NCs are pointing to one loolwsd, which works fine when editing local files. When i try to edit a shared file from the other NC the browser starts to load but ends with the message: “Failed to load Collabora Online Development Edition - please try again later”.

The hole setup exists for testing purposes in a virtualbox enviroment and is accessed over http.

In the loolwsd.xml i’ve added in the frame_anchestor section the http://* to allow the work on federated files.

Any suggestions where i’ve done the mistake?

Thank you!

Are you using NAT or bridge mode on the virtual NICs?

Hello,
i’ve set all NICs to internal Network. I’ve made my own private Network. 192.168.5.x/24
NC A 192.168.5.1
NC B 192.168.5.2
loolwsd 192.168.5.26
Client 192.168.5.23

All machines can ping each other. Most of the time i use ssh from the client to access the other machines. Today i’ve added a pfsense vm which allowed me to get inet access. Ive added this pfsense(192.168.5.100) as gateway in the netplan config on all machines. That didn’t change anything.

I’ve updated richdocuments to the latest Version 3.5.3. Nothing changed, so i will reinstall the loolwsd and start with a fresh config, maybe i’ve set something wrong.

Is there any documentation how the loolwsd.xml must be set to work with federated shares?

Hello,

i’ve reinstalled the loolwsd. Working locally on files with one or more users works just fine. Open shared files doesn’t.
what i’ve done in loolwsd.xml
disabled ssl
and followed this Post:

As i mentioned before i’ve added the ancestor_frame to http://* and not to https://* because i’m not using https.

I’ve started up wireshark to see what is going on and the interesting result is that the NCs does not talk to the 192.168.5.26 loolwsd Server when opening federated shared files. At local files it does! For federated shares there is not one entry for the ip of the loolwsd Server.

So can anyone help?

Is it making any failed DNS lookups that appear in your capture?

Unfortunately not because the net i set up has no DNS Domains. All Services are directly accessed through the IP. For example to access the webpage of one of my NCs i type in http://192.168.5.1. When i type in 192.168.5.26 i get the result OK from the loolwsd.

You can see the query which it does when it starts to open a non federated shared file:
http://192.168.5.26:9980/loleaflet/8228a56/loleaflet.html?WOPISrc=http%3A%2F%2F192.168.5.1%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F593_oc9e79u257ex&title=NC2.odt&lang=de&closebutton=1&revisionhistory=1

You should have a domain for your test network. Since you have pfSense running, I would host the zone there.

Nextcloud and Collabora are intended to be accessed via FQDN, and it’s also recommended to have different names for them, even if the IP is the same. It’s possible that could be part of your issue, and using DNS will give you a more production-like test environment. I think you can also run a CA on pfSense if you want to validate certs.

As soon as i have finished to set up the net like you mentioned i will come back and tell you what results i’ve achieved.

Greets

Ive set up FQDNs for all Servers in PFsense. After that i’ve build up the federation and added the FQDNs in the loolwsd.xml to be a trustet wopi host.

Nextcloud 1: 192.168.5.1 -> http://nextcloud1.mylocal
Nextcloud 1: 192.168.5.2 -> http://nextcloud2.mylocal
Loolwsd: 192.168.5.26 -> http://code.mylocal:9980 = OK

The result is the same. I can work locally on the files but when i want to edit a federated file it end with the result : Failed to load Collabora Online Development Edition - please try again later” on the Server which has accepted the share. The Server which started the sharing can open the file. I think thats because its local at this server. In wireshark i cant see anything good so far, no ask to the loolwsd accepting localfile editing.

I’ve put every possible combination in the frame_anchestor setting section. From http://* to http://nextcloud[1-2}{1}.mylocal. No change. Could it be that i need https to work on shared files in a federation? :confused:

That’s a distinct possibility. Nextcloud is designed to run over HTTPS, and many of its option features (Collabora to name one) have a variety of problems when running over HTTP.

In my setup, I have Nextcloud and Collabora behind a reverse proxy that they also use when accessing each other by name. Even though the proxy passes them both back over HTTP, they are establishing HTTPS connections, and both see valid certificates when doing so.

I think i’ve worked my way through to SSL on every instance.
NC1: https://nextcloud1.mylocal
NC2: https://nextcloud2.mylocal
loolwsd: https://code.mylocal:443

I wanted to setup the federation between the two NCS based on their https FQDNs but it cant dedect the NCs. I read online that i can not use self signed certificates, to setup a federation. Is that right? That would be bad, how to get this running :frowning:

Hmmmm… Well, I’m still not clear on whether that’s the cause or not, but I can tell you a couple ways to get fully valid Let’s Encrypt certs in play.

Method 1: Assuming the domains you used internally are ones you own or valid subdomains of ones you own, you could do manual DNS verification and then manually install the certs. You can do this pretty easily at https://zerossl.com/.

Method 2: You can set all instances of NC to run through a single reverse proxy and setup certbot on that proxy. You will have to have port 80 forwarded from the internet to the reverse proxy, but you don’t necessarily have to allow access to NC on port 80. It just has to be reachable and have site vhosts for those names and certbot should register them.

Also, when they say you can’t do it with self-signed certs, that may not necessarily be true; Offen times what that phrase really means is you can’t do it with a cert that isn’t recognized as valid or doesn’t have associated DNS records. Theoretically if all your self-signed certs are trusted but the servers and clients involved, and you’re running internal DNS with the appropriate records, that will generally work. Although it can be more complicated than just getting real certs.

Hey,
sorry for my late reply but there is some other work to do. So i will reply when i have finished that.
As a site note, OnlyOffice worked out off the box over HTTP with a shared file in the federation.

Hello friends! Have you found a solution? Ran into the same problem:

Two nextcloud, two collabora. All accessed over https, federated sharing works.

nc.test1.ru
nc.test2.ru

clbr.test1.ru
clbr.test2.ru

Added each other server to trusted servers list. (nc.test1.ru added on nc.test2.ru and reverse)

Added frame_anchestor settings

Now when I try to open documents, my page reloads, I see collabora interface (file,open menu, etc), without document for 1-2 sec, and returning to file list automaticaly

No log errors. Where to look?

After a long time i’ve stumbled again about the question if :

  1. code can open docs in a fed-share
  2. if the federated nc’s could open files on one central code
  3. is it possible to have 2xnc and 2x code

If someone stumbles accross, here is the solution:

If you want to use a central CODE server you’ll have to add them in coolwsd.xml so all nc-hosts are allowed to use the one code server.

With that my three questions can be answered as “yes”.