Allow List for WOPI requests

[marcusquinn]

@michaelpope Thanks for the creative thinking, we never know, huh! I just went to test this idea, and saw the 26.0.2 update has run — and guess what? It's just working again, all by itself. Nothing I did. So, maybe just something an app restart fixed.

I have some minor customisations, just in having the LibreSign bits installed, but nothing unofficial running.

I like to be verbose on issues in these forums, as they are like a Wiki for my future self and the Cloudron hive-mind, for if anything happens again, we have notes.

[ntnsndr]

Using 172.18.0.0/16 worked for me on the WOPI whitelist when using built-in CODE server.

[osobo]

@ntnsndr said in Allow List for WOPI requests:

Using 172.18.0.0/16 worked for me on the WOPI whitelist when using built-in CODE server.

Thank you. I think this is worth mentioning in the CODE setup documentation (https://docs.cloudron.io/apps/collabora/)

[nebulon]

Not sure if this applies to the collabora app we have on Cloudron, I think @ntnsndr is referring to the Nextcloud app which has some built-in code server? Although I wasn't aware that this works on Cloudron at all.

[osobo]

@nebulon FYI I use Cloudron's Collabora app. I needed to use the 172.18.0.0/16 WOPI whitelist setting just to remove the warning.

[nebulon]

Thanks, I've added a note about this in the docs https://docs.cloudron.io/apps/collabora/

[SebGG]

hi, i have a problem with the wopi adress i think. With wopi blank everything works as assumed. But with the wopi 172.18.0.0/16 not.

what could be wrong?

cloudron apps nextcloud and collabora online are installed at the same domain

[nebulon]

This setting is locking down the nextcloud host to only accept WOPI requests from collabora on that subnet, which is the local docker network on Cloudron. I have tried this here and setting 172.18.0.0/16 works as expected. Do you have any more information about the issue?

[nebulon]

@SebGG maybe your system is connecting via ipv6 only there so can you try to use fd00:c107:d509::/64 instead of the ipv4 one?

[SebGG]

Hi, no, the ipv6 adress also doesnt work. Is there a way to check this in a deeper way?

[nebulon]

Do you see any errors to work with?

For explanation, the collabora app backend will contact the Nextcloud instance. So Nextcloud can then only allow incoming requests on those routes by limiting to local connections with setting this netmask.

[SebGG]

I digged a bit deeper in and here are the logs for two requests for the same document. The first one is with the WOPI adress as documented and the second one it with my external real ipv4 adress. Withe the external real ipv4 adress it works and i can open the documents. i found that here "https://github.com/nextcloud/richdocuments/issues/2685"

With Wopi Adress 172.18.0.0/16:

"GET /index.php/apps/richdocuments/wopi/files/542576_oc2a6lhu6gbc?access_token=vmAdhoDd9DnOnITRqNn235KjCmxEUwjp&access_token_ttl=0 HTTP/1.1" 403 2 "-" "COOLWSD HTTP Agent 24.04.7.1"
"GET /index.php/apps/richdocuments/wopi/files/542576_oc2a6lhu6gbc?access_token=vmAdhoDd9DnOnITRqNn235KjCmxEUwjp&access_token_ttl=0&permission=edit HTTP/1.1" 403 2 "-" "COOLWSD HTTP Agent 24.04.7.1"

With Wopi Adress real IPv4 Adress :

"GET /index.php/apps/richdocuments/wopi/files/542576_oc2a6lhu6gbc?access_token=YGfINlPRSbkt7OLGw3VHMxuFSE19cX1v&access_token_ttl=0 HTTP/1.1" 200 853 "-" "COOLWSD HTTP Agent 24.04.7.1"
"GET /index.php/apps/richdocuments/wopi/files/542576_oc2a6lhu6gbc/contents?access_token=YGfINlPRSbkt7OLGw3VHMxuFSE19cX1v&access_token_ttl=0 HTTP/1.1" 200 6345 "-" "COOLWSD HTTP Agent 24.04.7.1"

[nebulon]

I am no WOPI expert and also cannot reproduce this still. A 403 status code would to me more look like the accesstoken (which is different in both requests you pasted) is invalid. But could be that Nextcloud does return a 403 also for blocked IPs. You have to ask the upstream developers for such details.

One idea, can you double check which IP range your local cloudron docker network uses? You can do this via SSH docker network inspect cloudron