richdocuments ignores custom webroot

[UltraBlackLinux]

Describe the bug
I cannot get nextcloud to open files via collabora. Whenever it tries to do so, it completely ignores my specified webroot and thus hits a 404 (it tries to get https://domain.com/custom_apps/richdocuments/... instead of https://domain.com/cloud/custom_apps/richdocuments/...). It's been months since I first discovered this, but it still hasn't been fixed sadly.

I've already tried using a standalone collabora server instead of the app, but no luck there either. The config has

'overwritewebroot' => '/cloud',
'overwrite.cli.url' => 'https://domain.com/cloud'

To Reproduce
Open a collabora document

Expected behavior
It should apply a custom webroot, /cloud in my case.

Client details:

• OS: Arch Linux
• Browser: Floorp
• Version: 11.7.1
• Device: Desktop

Server details

https://hub.docker.com/_/nextcloud/ (the official AIO image is a PITA to set up and has its fingers where I don't want them. Also kinda forces me to test on prod, so I'm not a fan)

Operating system: Arch linux

Web server: Whatever came with the docker image

Database: MariaDB

PHP version:

Nextcloud version: Whatever came with the docker image

Version of the richdocuments app latest, at this point it doesn't even seem to matter anymore...
Version of Collabora Online also latest

Configuration of the richdocuments app

{
    "apps": {
        "richdocuments": {
            "canonical_webroot": "",
            "disable_certificate_verification": "yes",
            "enabled": "yes",
            "external_apps": "",
            "installed_version": "8.2.4",
            "public_wopi_url": "https:\/\/domain.com\/cloud\/custom_apps\/richdocumentscode\/proxy.php?req=",
            "types": "prevent_group_restriction",
            "wopi_allowlist": "",
            "wopi_url": "https:\/\/domain.com\/cloud\/cloud\/custom_apps\/richdocumentscode\/proxy.php?req="
        }
    }
}

Logs

Nextcloud log (data/nextcloud.log)

file too big?
https://chonkyrabbit.eu/files/_share/SArXp-nextcloud.log

Browser log

POST
	https://domain.com/custom_apps/richdocumentscode/proxy.php?req=/browser/f76e08a/cool.html?WOPISrc=https://domain.com/cloud/index.php/apps/richdocuments/wopi/files/1399_oc2zcelp23cu&title=/foovar.odp&lang=en&closebutton=1&revisionhistory=1
Status
404
Not Found
VersionHTTP/2
Transferred918 B (643 B size)
Referrer Policyno-referrer

[joshtrichards]

Try:

occ config:app:delete richdocuments canonical_webroot

Also your wopi_url looks bogus:

            "wopi_url": "https:\/\/domain.com\/cloud\/cloud\/custom_apps\/richdocumentscode\/proxy.php?req="

[UltraBlackLinux]

Try

Now I'm getting this error each time I try to access a document: Exception: Could not find urlsrc in WOPI

Also your wopi_url looks bogus

Yeah I noticed that as well, but that's like the opposite of what it's doing right now. I wonder what I should do about that...

[joshtrichards]

That's progress I think. That exception indicates probably a problem with discovery, which is driven by the wopi_url so let's fix that. It should be sufficient to go to Admin settings->Nextcloud Office then toggle from "Use the built-in CODE" to "Use your own server" then back to trigger the auto-populated value (I think - some recent changes were made here and not all of those are in the version of the app you're using; logging has been improved recently too but that's not in v8.2.x).

If not it can always be overridden via occ.

[UltraBlackLinux]

that sadly didn't fix it. Now we're back to the missing custom web root...

[joshtrichards]

In the browser or in the settings themselves?

What's the new occ config:list richdocuments?

[UltraBlackLinux]

That's in the browser. it's making a 404 request, since it's missing the /cloud prefix
"public_wopi_url": "https:\/\/domain.com\/custom_apps\/richdocumentscode\/proxy.php?req=",
oh would you look at that. There is the culprit all of a sudden.

The other wopi url is still wrong but this is broken indeed.

Edit: I just managed to modify the public_wopi_url, and it's now correct (my browser is still making 404 requests, even after clearing the cache), but the wopi_url still keeps the second /cloud, even after setting it to the same value as public_wopi_url...

Edit 2: I just restarted nextcloud, got the url error again, toggled the built-in collabora server again, and now the values are back to the invalid defaults?? What is going on?

[joshtrichards]

What does your apps_paths look like from occ config:list system?

[UltraBlackLinux]

"apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],

I've seen setups without that kind of separation, but I think I got most of my config file from the docker image I linked.

[joshtrichards]

I just restarted nextcloud, got the url error again, toggled the built-in collabora server again, and now the values are back to the invalid defaults?? What is going on?

Unfortunately (well, fortunately really - but less so from a troubleshooting your situation perspective) the logic was drastically changed (improved, hopefully!) for the auto-configuration in #3315. Unfortunately you won't see that unless you're on NC28. But the recent changes also makes it challenging for me to keep straight in my head what could be going on in your particular case.

I've seen setups without that kind of separation, but I think I got most of my config file from the docker image I linked.

Yeah that's fine.

Maybe try this:

• Don't toggle anything else in the Web UI settings
• Manually set the wopi_url to be correct via occ
• Manually set the public_wopi_url to be correct via occ
• Restart your web/app server (to make sure opcache doesn't keep around the old values)
• Try to access from a private browsing session or something (to make sure everything's all clean browser side after changing the values)

P.S. For the record, are you using the fpm Docker image + nginx (or something) or the apache Docker image?

[UltraBlackLinux]

• Manually set the wopi_url to be correct via occ

As I said previously, I seemingly cannot change that value. I set it, and when I check it, I see the old value again...
I'm getting the previously mentioned Could not find urlsrc in WOPI error regardless. It tries to access /apps/richdocuments/token and instead gets an internal server error back. This only happens after I modify the public_wopi_url

P.S. For the record, are you using the fpm Docker image + nginx (or something) or the apache Docker image?

That is the apache image, yes

Edit: I just noticed that it's highlighting a few errors at once when clicking on the bottom urlsrc error, and this too: Trying to access array offset on value of type null at /var/www/html/custom_apps/richdocuments/lib/WOPI/DiscoveryManager.php#132 (line 130, 131, and 132)

I'm also seeing this error: GET https://domain.com/cloud/cloud/custom_apps/richdocumentscode/proxy.php?req=/hosting/capabilities resulted in a 404 Not Found. There's the broken url that doesn't want to be changed.

[joshtrichards]

You previously stated you're just using the standard Docker image, but that doesn't support subfolder based installations by default. Do you have a proxy in front / where is your external https URL actually terminating?

[UltraBlackLinux]

I am running caddy yeah.

I'm confused why you're saying that the image does not support that. The readme clearly states the instructions for a subfolder based installation (at least when using the apache image): https://github.com/docker-library/docs/blob/master/nextcloud/README.md#using-the-apache-image-behind-a-reverse-proxy-and-auto-configure-server-host-and-protocol

On top of that, I think my setup is the intended purpose for the Apache image, otherwise I don't think the TRUSTED_PROXIES environment variable would make sense

[joshtrichards]

I am running caddy yeah.

That's extremely important information.

The readme clearly states the instructions for a subfolder based installation (at least when using the apache image):

You're accessing NC via a subfolder path at the proxy level, but it's not actually installed in a subfolder.

As a result it's your proxy that is responsible for stripping the subfolder piece from the URL before proxying to Nextcloud.

The overwritewebroot let's NC know to include the subfolder back where needed (when generating URLs for external use) so that things work, but NC shouldn't be getting passed URLs with the subfolder still in it by your proxy (since it's not actually a subfolder installation of NC).

You need to look at how to do that with Caddy. There are a couple ways. handle_path and/or stri_prefix come to mind.

This is all starting to make way more sense.

Subfolder installations of NC used to be really common (probably are a bit less today, but are still common enough). I was surprised to hear you were having such challenges using one.

But you actually aren't using a subfolder installation at all. :)

[UltraBlackLinux]

That's extremely important information.
You're accessing NC via a subfolder path at the proxy level, but it's not actually installed in a subfolder.
But you actually aren't using a subfolder installation at all. :)

Oh my bad, I'm sorry.

handle_path

I'm already using that, so I doubt my proxy's configuration is the culprit. I actually know that it is working. The first time I installed nextcloud, I actually got collabora working flawlessly (and I can't recall breaking my caddy config), but I accidentally killed the process, which corrupted the database, and one install later, it wasn't working anymore, and still isn't up to this day...

redir /cloud /cloud/ 308
handle_path /cloud/* {
    reverse_proxy nextcloud:80
}

The overwritewebroot let's NC know to include the subfolder back where needed

This however doesn't explain why it's not letting me fix the public_wopi_url, and has one to many overwritewebroot prefixes in the wopi_url

[UltraBlackLinux]

I've just noticed something really weird about the /cloud/cloud problem. If I copy the correct public_wopi_url and modify it only slightly and try to use that for wopi_url, it takes the url without modifying it. What is going on? Why does that check even exist??

Here's some examples that work:

• https://domain.com/cloud/custom_apps/richdocumentscode/proxy.php?reqa=
• https://domain.com/cloud/custom_apps/richdocumentscode/proxy.php?req\\= (it auto escapes a single backslash... sigh)
• https://domain.com/cloud/custom_apps/richdocumentscode/proxy.php?req

This gets converted back: https://domain.com/cloud/custom_apps/richdocumentscode/proxy.php?req=

[UltraBlackLinux]

any updates on this? I really want this to work and I still have no idea why it's not working for me...