[BUG]: Invalid WOPI Allow list isn't communicated to the user

[byteit101]

Describe the bug
WOPI allow list is not honored. If the whitelist is not empty, all accesses to
/index.php/apps/richdocuments/wopi/files/.... from all IP addresses return a 403 Forbidden response

To Reproduce
Steps to reproduce the behavior:

1. Install 7.0.2 on 25.0.2
2. Ensure WOPI allow list is empty
3. Collabora office opens as /index.php/apps/richdocuments/wopi/files/.... returns 200's
4. Set WOPI allow list to all relevant IP addresses
5. Collabora office fails to open as /index.php/apps/richdocuments/wopi/files/.... returns 403's

Confirmed the ip addresses to add with Wireshark. Both the actual ip.src and http.x_forwarded_for values are in the WOPI allow list of step 4.

Expected behavior
Allowing 127.0.0.1 should not provide 403's to 127.0.0.1

Client details:

• OS: Debian 11 x64
• Browser: cURL, Wireshark, Chrome, Firefox, and all other HTTP clients
• Version 25.0
• Device: Server, Desktop

Server details

Operating system: Docker on Debian 11 x64

nextcloud latest 60c973f14214 8 days ago 1.02GB

Web server: Apache 2.4

Database: Postgres

PHP version: PHP 8.1.13

Nextcloud version: 25.0.2

Version of the richdocuments app 7.0.2

Version of Collabora Online collabora/code latest 27ebaa6d94c9 3 weeks ago 1.54GB

Logs

Nextcloud log (data/nextcloud.log)

(no output, even at logging level = 0)

Someone else has run into this too: https://help.nextcloud.com/t/in-nextcloud-office-i-can-t-make-wopi-allowlist-work/152004

[pagiraud]

Yes, I’m the "someone else". Issues are very probably strongly related, although my Nextcloud and Collabora instances are on separate computers (hence 127.0.0.1 is not relevant in my case).

[juliusknorr]

We are using the server method to determine the remote address https://github.com/nextcloud/server/blob/cf508c1e4730f3590b956735678413484e2c008c/lib/private/AppFramework/Http/Request.php#L584-L611

Do you run reverse proxy in front of Nextcloud? If so is that one listed in the trusted_proxies config?

[byteit101]

Yes, and yes, 127.0.0.1 is in the trusted proxies

[juliusknorr]

Can you maybe try to apply the following patch to get logging at info log level to see what the actual detected ip is and then share that together with your configured allow list?

#2688

Details on how to apply a patch can be found in https://docs.nextcloud.com/server/latest/admin_manual/issues/applying_patch.html

[byteit101]

{
  "reqId": "SNIP",
  "level": 1,
  "time": "2022-12-20T12:18:27+00:00",
  "remoteAddr": "172.18.0.2",
  "user": "--",
  "app": "richdocuments",
  "method": "GET",
  "url": "/index.php/apps/richdocuments/wopi/files/...SNIP...&permission=edit",
  "message": "WOPI request denied from 172.18.0.2 as it does not match the configured ranges: 127.0.0.1 172.0.0.0/8",
  "userAgent": "COOLWSD HTTP Agent 22.05.8.4",
  "version": "25.0.2.3",
  "data": {
    "app": "richdocuments"
  }
}

My allow list is as it says in the log

[juliusknorr]

Can you check if you added the allow list separated by spaces? If that is the case maybe you can set that to a comma separated list: 127.0.0.1,172.0.0.0/8

Regardless of that we should of course either warn the admin when configuring it like that or support both.

[byteit101]

Yes, it is separated by spaces. Adding commas didn't work either until I deleted the space after the comma. IE:

• Fail: 127.0.0.1 172.0.0.0/8
• Fail: 127.0.0.1, 172.0.0.0/8
• Work: 127.0.0.1,172.0.0.0/8

I agree, this should at a minimum warn if it can't parse what's entered

[pagiraud]

The problem is not solved for me. From the beginning I use commas and I also tried with one only address.

I tried to apply the patch but it asks me the file to patch and the lib/Middleware/WOPIMiddleware.php doesn’t exist (actually, the directory lib/Middelware doesn’t neither). Should I create it?

[byteit101]

@pagiraud The linked documentation is non-obvious. I ran into that issue too, until I realized it meant to do it in the right subfolder:

root@a996aca55416:/var/www/html# cd custom_apps/richdocuments/
root@a996aca55416:/var/www/html/custom_apps/richdocuments# patch -p 1 < ../../data/2688.patch 
patching file lib/Middleware/WOPIMiddleware.php
Hunk #1 succeeded at 105 (offset 1 line).

More on point, I would also agree that a full fix for this issue should include a warning to the user if it's invalid

[pagiraud]

@byteit101 Thanks for the tip!

{"reqId":"aaaaa",
"level":1,
"time":"2022-12-20T23:30:57+01:00",
"remoteAddr":"myIPv6Address",
"user":"--",
"app":"richdocuments",
"method":"GET",
"url":"/index.php/apps/richdocuments/wopi/files/…",
"message":"WOPI request denied from myIPv6Address as it does not match the configured ranges: myIPv6Address",
"userAgent":"COOLWSD HTTP Agent 22.05.8.4",
"version":"25.0.2.3",
"data":{"app":"richdocuments"},
"id":"aaaaaa"
}

First, I tried with my ipv4 address and the logs yielded, so I copied/pasted the address from the message to the WOPI configuration field and… still doesn’t work. Does this mean that WOPI doesn’t work with ipv6? I assure you every occurrence of "myIPv6Address" is the same. I did a search and replace to be sure. And I checked: no space in the field, neither before nor after the ip.

@juliushaertl Maybe you could reopen this issue?

[juliusknorr]

For IPv6 I just checked and it seems there is a small bug if no prefix length is specified. If you just have ipv6 address in the allow list, could you try to specify that ip with appending /128 to the IP? I'll push a fix shortly for this, but would be nice to see fi that already fixes the issue for you.

[pagiraud]

Yes, that works for me! Thank you.

[juliusknorr]

Thanks for testing and confirming that. I pushed a fix and tests for it to #2696

[vasyugan]

For me, the WOPI allow list only works with Nextcloud instances that are on a different host than the Collabora server. Adding 127.0.0.1 and ::1 to the allow list doesn't fix this. nextcloud.log should at least say which connections, from which IP addresses it refused. Without that, I am fumbling in the dark.

[VPaulV]

I agree, would be awesome if in the error message we would have also IP (not only domain name)

[mrtumnus]

For me, the WOPI allow list only works with Nextcloud instances that are on a different host than the Collabora server. Adding 127.0.0.1 and ::1 to the allow list doesn't fix this. nextcloud.log should at least say which connections, from which IP addresses it refused. Without that, I am fumbling in the dark.

@vasyugan The Nextcloud Office frontend apparently uses the external IP of the Collabora/WOPI backend, not the localhost IP, presumably to allow more flexibility in deployment architecture. If you add <externalIP> (see log entry below) to the WOPI allow list, the error will resolve and Nextcloud Office should work properly. No need to run Collabora on a separate server.

I agree, would be awesome if in the error message we would have also IP (not only domain name)

@VPaulV The log does tell you what IP it's trying to use (set log level to 1 or less in config.php). For example, if you had 127.0.0.1,::1 in your WOPI allow list, the following error will show in the log:

{"reqId":"xxxxxxxxx","level":1,"time":"2023-07-06T16:03:16+00:00","remoteAddr":"<externalIP>","user":"--","app":"richdocuments","method":"GET","url":"/index.php/apps/richdocuments/wopi/files/xxxxxxxxxxxxxxxx...","message":"WOPI request denied from <externalIP> as it does not match the configured ranges: 127.0.0.1,::1","userAgent":"COOLWSD HTTP Agent 23.05.1.2","version":"26.0.3.2","data":{"app":"richdocuments"}}

[mrtumnus]

This issue is resolved for me. Thanks @juliushaertl !

[mrtumnus]

As a separate issue, perhaps the "WOPI request denied" error message should be WARN (2) or ERROR (3) level, rather than INFO (1). config.php by default has log level set to WARN, which will hide these messages.

[MaoMaoCake]

Not sure if this is of use but I'm running AIO and I put the IP server that the AIO Image is running on. The local IP not the public IP like 192.168.1.100

[panomitrius]

Can't get my setup to work

So far I haven't found any combinations of allow ip's that lets me access documents through Nextcloud, but if I leave the allow list empty it works.

Docker on Ubuntu 22.02
Nextcloud version: 27.0.2.1
Version of the richdocuments app: 23.05.3.1
Version of Collabora Online: 23.05.3.1

This are the logs after setting it to: "127.0.0.1,172.0.0.0/8":

frk-00031-00031 2023-09-01 11:14:15.686238 +0000 [ forkit ] WRN  The systemplate directory [/opt/cool/systemplate] is read-only, and at least [/opt/cool/systemplate//etc/hosts] is out-of-date. Will have to copy sysTemplate to jails. To restore optimal performance, make sure the files in [/opt/cool/systemplate/etc] are up-to-date.| common/JailUtil.cpp:524
frk-00031-00031 2023-09-01 11:14:27.374800 +0000 [ forkit ] WRN  The systemplate directory [/opt/cool/systemplate] is read-only, and at least [/opt/cool/systemplate//etc/hosts] is out-of-date. Will have to copy sysTemplate to jails. To restore optimal performance, make sure the files in [/opt/cool/systemplate/etc] are up-to-date.| common/JailUtil.cpp:524
wsd-00001-00528 2023-09-01 11:14:27.429581 +0000 [ docbroker_01b ] ERR  WOPI::CheckFileInfo failed for URI [https://nextcloud.mydomain.com/index.php/apps/richdocuments/wopi/files/1087779_octr54p6hjbf?access_token=KI1B59mwU77NMAsSIs0QPCJPBxW9S0XO&access_token_ttl=1693602854000&permission=edit]: 403 (Forbidden) Forbidden. Headers: 	Server: nginx / 	Date: Fri, 01 Sep 2023 11:14:27 GMT / 	Content-Type: application/json; charset=utf-8 / 	Content-Length: 2 / 	Connection: keep-alive / 	Referrer-Policy: no-referrer / 	X-Content-Type-Options: nosniff / 	X-Frame-Options: SAMEORIGIN / 	X-Permitted-Cross-Domain-Policies: none / 	X-Robots-Tag: noindex, nofollow / 	X-XSS-Protection: 1; mode=block / 	X-Powered-By: PHP/8.2.9 / 	Set-Cookie: octr54p6hjbf=73cdff9456ca491856dbbb1fc4aa933c; path=/; secure; HttpOnly; SameSite=Lax / 	Expires: Thu, 19 Nov 1981 08:52:00 GMT / 	Cache-Control: no-cache, no-store, must-revalidate / 	Pragma: no-cache / 	Content-Security-Policy: default-src 'none';base-uri 'none';manifest-src 'self';frame-ancestors 'none' / 	X-Request-Id: p4MBCAmpUtuk8S6lVxCy / 	Feature-Policy: autoplay 'none';camera 'none';fullscreen 'none';geolocation 'none';microphone 'none';payment 'none' / 	Body: [[]]| wsd/Storage.cpp:708
wsd-00001-00528 2023-09-01 11:14:27.429701 +0000 [ docbroker_01b ] ERR  loading document exception: Access denied, 403. WOPI::CheckFileInfo failed on: https://nextcloud.mydomain.com/index.php/apps/richdocuments/wopi/files/1087779_octr54p6hjbf?access_token=KI1B59mwU77NMAsSIs0QPCJPBxW9S0XO&access_token_ttl=1693602854000&permission=edit| wsd/DocumentBroker.cpp:2610
wsd-00001-00528 2023-09-01 11:14:27.429750 +0000 [ docbroker_01b ] ERR  Failed to add session to [https%3A%2F%2Fnextcloud.mydomain.com%3A443%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F1087779_octr54p6hjbf] with URI [https://nextcloud.mydomain.com/index.php/apps/richdocuments/wopi/files/1087779_octr54p6hjbf?access_token=KI1B59mwU77NMAsSIs0QPCJPBxW9S0XO&access_token_ttl=1693602854000&permission=edit]: Access denied, 403. WOPI::CheckFileInfo failed on: https://nextcloud.mydomain.com/index.php/apps/richdocuments/wopi/files/1087779_octr54p6hjbf?access_token=KI1B59mwU77NMAsSIs0QPCJPBxW9S0XO&access_token_ttl=1693602854000&permission=edit| wsd/DocumentBroker.cpp:2572
wsd-00001-00528 2023-09-01 11:14:27.429785 +0000 [ docbroker_01b ] ERR  Unauthorized Request while starting session on https%3A%2F%2Fnextcloud.mydomain.com%3A443%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F1087779_octr54p6hjbf for socket #24. Terminating connection. Error: Access denied, 403. WOPI::CheckFileInfo failed on: https://nextcloud.mydomain.com/index.php/apps/richdocuments/wopi/files/1087779_octr54p6hjbf?access_token=KI1B59mwU77NMAsSIs0QPCJPBxW9S0XO&access_token_ttl=1693602854000&permission=edit| wsd/COOLWSD.cpp:5042
wsd-00001-00528 2023-09-01 11:14:27.446821 +0000 [ docbroker_01b ] ERR  #18: Read failed, have 0 buffered bytes (ECONNRESET: Connection reset by peer)| net/Socket.hpp:1122
wsd-00001-00528 2023-09-01 11:14:27.446881 +0000 [ docbroker_01b ] WRN  #18: Unassociated Kit (527) disconnected unexpectedly| wsd/COOLWSD.cpp:3491
sh: 1: /usr/bin/coolmount: Operation not permitted
sh: 1: /usr/bin/coolmount: Operation not permitted
sh: 1: /usr/bin/coolmount: Operation not permitted

Any ideas?

[panomitrius]

Solved it, had to add the servers real external IP address also, for some reason.

[joshtrichards]

Fixed across several PRs. The most recent, #3261, enhanced logged further. Closing.