WOPI allow list breaks document loading with any non-empty value (Nextcloud AIO)

[pmilosev]

Describe the bug

Fresh Nextcloud AIO installation (32.0.6) with richdocuments 9.0.3.
Setting any non-empty value for wopi_allowlist causes Nextcloud Office to fail to load documents.
An empty allowlist works correctly.

When wopi_allowlist is misconfigured, document opening fails due to missign permissions -> this is correct behaviour.
When wopi_allowlist is set to an appropriate value, opening an ODT file shows "Loading xyz.odt" briefly, then "Nextcloud Office | Connecting", which loops indefinitely.
Even setting the allow list to something like 0.0.0.0/0 which should match all IPs the issue remains (it's not a filtering issue).
Without any value (no IP filtering) the document opens correctly.

Browser console logs show repeated HTTP 400 responses where Collabora is trying to load ./browser/.../%LOGO_URL%.
It seems like a template variable or something is not being substituted.
In the working case (empty allowlist), this resolves to ./images/minus.svg.

Collabora container logs show Internal Server Error (500) on all template preset URI fetches (e.g. Ecosystem.odp, Elegant.odp, Simple.odp, etc.), followed by:

ERR  Failed to load all settings from [http://nextcloud-aio-apache:23973/index.php/apps/richdocuments/wopi/settings?type=userconfig&access_token=...&fileId=-1]

(http://nextcloud-aio-apache:23973 is the NC AIO Colabora online server)

WOPI requests arrive from three different source IPs:

• 127.0.0.1 - internal Collabora-to-Nextcloud calls via AIO Apache
• Docker host IP - requests routed through the Docker network
• Browser public IP - initial token requests from the client

As mentioned, even adding all three to the allowlist, or using 0.0.0.0/0, does not resolve the issue.
Only an empty wopi_allowlist value works.

To Reproduce

1. Install Nextcloud AIO 32.0.6 behind a reverse proxy (nginx), following the AIO reverse proxy documentation.
2. Confirm Nextcloud Office works with an empty wopi_allowlist (documents open normally).
3. Set any non-empty wopi_allowlist value (e.g. 0.0.0.0/0)
4. Try to open an ODT file.
5. Observe infinite "Connecting" loop.

Expected behavior
Setting wopi_allowlist to the specific IPs that make WOPI requests should allow documents to load normally, as it does when the allowlist is empty.

Client details:

• OS: Linux (KDE Plasma 6 / Wayland)
• Browser: Firefox 148.0
• Device: Desktop

Server details

Operating system: Ubuntu (Nextcloud AIO Docker)

Web server: nginx (reverse proxy) → AIO Apache/Caddy → Nextcloud

Nextcloud version: 32.0.6.1 (Hub 25)

Version of the richdocuments app: 9.0.3

Configuration of the richdocuments app

{
    "apps": {
        "richdocuments": {
            "installed_version": "9.0.3",
            "types": "filesystem,prevent_group_restriction",
            "enabled": "yes",
            "wopi_callback_url": "http:\/\/nextcloud-aio-apache:23973",
            "public_wopi_url": "https:\/\/<DOMAIN>",
            "doc_format": "",
            "use_groups": "",
            "canonical_webroot": "",
            "disable_certificate_verification": "",
            "external_apps": "",
            "wopi_url": "http:\/\/nextcloud-aio-apache:23973",
            "wopi_allowlist": "0.0.0.0\/0"
        }
    }
}

Logs

#### Collabora log (failing case — wopi_allowlist set)

wsd ERR  Failed to fetch preset uri[https://<DOMAIN>/apps/richdocuments/settings/userconfig/<TOKEN>/template/Simple.odp?identifier=22] with status[Internal Server Error]
wsd ERR  Failed to fetch preset uri[https://<DOMAIN>/apps/richdocuments/settings/userconfig/<TOKEN>/template/Ecosystem.odp?identifier=25] with status[Internal Server Error]
wsd ERR  Failed to fetch preset uri[https://<DOMAIN>/apps/richdocuments/settings/userconfig/<TOKEN>/template/Elegant.odp?identifier=26] with status[Internal Server Error]
[... all template presets fail with 500 ...]
wsd ERR  Failed to load all settings from [http://nextcloud-aio-apache:23973/index.php/apps/richdocuments/wopi/settings?type=userconfig&access_token=<TOKEN>&fileId=-1]
wsd WRN  Unassociated Kit disconnected unexpectedly

Nextcloud log (for a single 500 template request — no error above level 1)

{"reqId":"<ID>","level":0,"time":"...","remoteAddr":"10.0.1.1","user":"--","app":"richdocuments","method":"GET","url":"/apps/richdocuments/settings/userconfig/<TOKEN>/template/Simple.odp?identifier=22","message":"OCA\\Richdocuments\\Controller\\SettingsController::getSettingsFile uses the @PublicPage annotation and should use the #[OCP\\AppFramework\\Http\\Attribute\\PublicPage] attribute instead"}
{"reqId":"<ID>","level":0,"time":"...","remoteAddr":"10.0.1.1","user":"--","app":"richdocuments","method":"GET","url":"/apps/richdocuments/settings/userconfig/<TOKEN>/template/Simple.odp?identifier=22","message":"Loaded WOPI Token record: {\"id\":608,\"owner_uid\":\"admin\",\"editor_uid\":\"admin\",\"fileid\":-1,\"version\":\"25.04.8.3\",\"canwrite\":true,...,\"token_type\":5}."}
{"reqId":"<ID>","level":1,"time":"...","remoteAddr":"10.0.1.1","user":"--","app":"no app in context","method":"GET","url":"/apps/richdocuments/settings/userconfig/<TOKEN>/template/Simple.odp?identifier=22","message":"The app config key files/watermark_enabled is not defined in the config lexicon"}

No level 2+ entries logged. The 500 is returned without any captured PHP exception.

NOTE: Anyone reading this trying to get WOPI IP whitelisting working - 0.0.0.0/0 is used only for debugging and is not a secure setting. It whitelists all IP addresses and is identical to having no allowlist set.

[juliusknorr]

Thanks for reporting. This is an interesting case, I had not been able to reproduce this. From the code I so far cannot see how the wopi allow list may influence this. I prepared a small logging patch to properly log the catched exceptions that I suspect to fail #5492

Would you be able to apply this patch from https://github.com/nextcloud/richdocuments/pull/5492.patch to the richdocuments app (see https://docs.nextcloud.com/server/latest/admin_manual/issues/applying_patch.html for more details) and gather logs again after reproducing with that in place?