In Nextcloud Office, I can’t make wopi_allowlist work

I’ve got two servers at home. On one (serv.a), I’ve got Nextcloud installed and working. On the other one, (serv.b), I’ve got a Collabora server. The servers have separate domain names.

I’ve installed Nextcloud office and filled the mains fields. When opening a file, everything’s fine: it launches the Collabora interface and I can edit my document.

But, I would like to fill the field “Allow list for WOPI requests”. I’ve tried many things : public IP of serv.b, local IP of serv.b, in IPv4 and in IPv6, IPv6 prefix, IPv4 local subnet… nothing works and when trying to open a file it ends up by saying “Please try again later”.

Did I miss something or is there a bug?

Best regards,

1 Like

I have also encountered this, and I even got wireshark involved: my proxy sends requests from 127.0.0.1 to 127.0.0.1 with X-Forwarded-For: 172.16.0.2, and putting both of those ip addresses, plus my public, link local, and local-network IP addresses in the WOPI field failed, so I filed a bug: [BUG]: Allow list for WOPI requests isn't honored · Issue #2685 · nextcloud/richdocuments · GitHub

Looks like we can’t enable the allow list until this bug is fixed

3 Likes

I had the same problem with the WOPI requests.
An empty field always works. If my public IP is in this field, then no document is opened.
I have Collabora CODE running in Docker and Nextcloud 25.0.2 natively on the same device.
The Collabora CODE server is accessible with a subdomain and also works with an externally hosted Nextcloud, just not with my Nextcloud.
In my case, I have now found the cause.
In my case, it was due to an incorrect setting in the Pi-hole.
I entered my Nextcloud subdomain under Local DNS Records. That was wrong!
After I removed this entry, opening the documents worked again without an error message.
I have now entered the IP address ranges of my provider in the field.
These ranges can be found here, for example.
Telekom
Vodafone

Finally, it seems we encountered three different problems. @Crashandy found a solution by (him|her)self while @byteit101 and I were helped on Github by @juliushaertl For the last two of us, fixes should soon happen so nobody stumbles upon this after next release. Before that, two things to note:

  • If you enter a list of IP or ranges, separate them by a comma only (no space at all) such as in 127.0.0.1,192.168.0.1 (@byteit101 problem)
  • If you enter an IPv6, append a prefix length: /128 if you enter a full IPv6 (my problem)

Thanks to all for helping sorting that out.

3 Likes

Thanks! Adding the prefix length to IPv6 addresses was exactly what solved this for me as well.

1 Like

What exactly did you do in order to identify the IP address in wireshark? My collabora is reverse proxied by NGINX, while nextcloud is directly running on NGINX. Which requests did you intercept?

UPDATE: I now added the ip address of the docker container shown by docker container inspect [name of collabora container], and now it works! Yay!

Just in case somebody still has this problem: My nextcloud runs on the host, behind nginx, collabora is running in docker as well behind nginx. I sheepishly allowed 127.0.0.1 and my public ip. But I forgot that the container has its own private address. So I added the private ip range (since who knows when the containers IP changes…) I setup for docker (there is only the collabora container on the system anyways) and it worksl

1 Like

I tried to allow all IPv4 adresses 0.0.0.0/0 but that doesn’t work for me (Hetzner Storage Share, Collabora running on an different VM with nginx reverse proxy).

Update: ::/0 works.

If you put in 0.0.0.0/0 or ::/0 you could as well just leave it blank :wink:

I put the gateway IP of my router/firewall into. That works.

I don’t understand. If I select Built-in Code, why simply it could lock those restrictions to the localhost? Does it mean I was exposed to the security hole all that time?