Cant set public_wopi_url with port

[AdminMgl]

Describe the bug
Since the last update of richdocuments, it no longer seems to be possible to use a public_wopi_url with a port. Before that, it worked fine. Therefore, documents can no longer be opened. Accordingly, there is no error message, except for the 404 in the access.log, since the URL (without the port) is wrong.

To Reproduce
Steps to reproduce the behavior:

1. occ config:app:set richdocuments public_wopi_url --value “https://domain.tld:9981”
   Output: "Config value 'public_wopi_url' for app 'richdocuments' is now set to 'https://domain.tld:9981', stored as mixed in fast cache"
2. occ richdocuments:activate-config

✓ Reset callback url autodetect
Checking configuration
🛈 Configured WOPI URL: https://domain.tld:9981
🛈 Configured public WOPI URL: https://domain.tld:9981
🛈 Configured callback URL: 

✓ Fetched /hosting/discovery endpoint
✓ Valid mimetype response
✓ Valid capabilities entry
✓ Fetched /hosting/capabilities endpoint
✓ Detected WOPI server: Collabora Online Development Edition 24.04.7.2

Collabora URL (used for Nextcloud to contact the Collabora server):
  https://domain.tld:9981
Collabora public URL (used in the browser to open Collabora):
  https://domain.tld                                                       **<---- NO PORT** 
Callback URL (used by Collabora to connect back to Nextcloud):
  autodetected (will use the same URL as your user for browsing Nextcloud)

3. occ richdocuments:activate-config (For the second time.)

🛈 Configured public WOPI URL: https://domain.tld             **<---- NO PORT** 

Expected behavior
It would be expected that the port would not be deleted.

Server details

Operating system:
Ubuntu 20.04

Web server:
nginx 1.27.1

Database:
mariadb 11.4.3

PHP version:
php8.3
Nextcloud version:
29.0.7
Version of the richdocuments app
8.4.6
Version of Collabora Online
24.04.7.2
Configuration of the richdocuments app

{
    "apps": {
        "richdocuments": {
            "disable_certificate_verification": "",
            "enabled": "yes",
            "installed_version": "8.4.6",
            "public_wopi_url": "https:\/\/waldorf-mgl.ddns.net",
            "types": "prevent_group_restriction",
            "wopi_allowlist": "127.0.0.1,192.168.2.0\/24,192.168.3.1",
            "wopi_callback_url": "",
            "wopi_url": "https:\/\/waldorf-mgl.ddns.net:9981"
        }
    }
}

Logs

Nextcloud log (data/nextcloud.log)

Nothing.

Part of access.log

POST /browser/d5ebff5/cool.html?WOPISrc=https%3A%2F%[2Fdomain.tld](http://2fdomain.tld/)%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F2286_ocevrh27radx&title=%2FDokumente%2FTest1.odt&lang=de&closebutton=1&revisionhistory=1 HTTP/2.0” 404 4665

[SimeonEhrig]

I can confirm the problem. In my case it set the http protocol in the config entry public_wopi_url instead the https protocol. Therefore no connection was possible.

$ php occ config:list richdocuments
{
    "apps": {
        "richdocuments": {
            "disable_certificate_verification": "",
            "enabled": "yes",
            "installed_version": "8.5.2",
            "public_wopi_url": "http:\/\/office.example.de:19443",
            "types": "prevent_group_restriction",
            "wopi_url": "https:\/\/office.example.de:19443"
        }
    }
}

Setting the configuration field manually via php occ config:app:set richdocuments public_wopi_url --value "https://office.example.de:19443" didn't solved the problem.

$ php occ config:list richdocuments
{
    "apps": {
        "richdocuments": {
            "disable_certificate_verification": "",
            "enabled": "yes",
            "installed_version": "8.5.2",
            "public_wopi_url": "https:\/\/office.example.de:19443",
            "types": "prevent_group_restriction",
            "wopi_url": "https:\/\/office.example.de:19443"
        }
    }
}

[elzody]

I am unfortunately unable to reproduce this issue myself on this version of NC server and richdocuments. There have been some updates to richdocuments (and server) since then, would you be able to update the server and app to see if it resolves the issue?

[SimeonEhrig]

No, unfortunately not. I updated to richdocuments 8.5.2 and Nextcloud 30.0.1 (from 29.0.8) at the same time, therefore I'm not sure who introduced the bug.

[elzody]

@AdminMgl any news/further info from you?

[SimeonEhrig]

@elzody I can setup a fresh nextcloud instance to test my existing collobora container if this help. Maybe I triggered a bug caused by the update process.

[elzody]

@SimeonEhrig sure, would be happy to know the result.

[SimeonEhrig]

Okay, takes me a little bit time. But I think until Friday I should get manage it. Maybe earlier.

[SimeonEhrig]

I can reproduce with a fresh installed Nextcloud instance. I use the Nextcloud Docker container.

• Nextcloud 30.0.1
• richdocuments 8.5.2

[wrighrc]

Please fix this. Here's a screenshot where I go to
https://nextcloud.charleswright.co:8443/index.php/settings/admin/richdocuments
Type in the URL and Port and then it clearly ignores the port.

I'm running Nextcloud 30.0.4 (latest at the time of post)

[wrighrc]

@elzody I think this should be reproducible, I run my nextcloud on 8443, so I'd try configuring a nextcloud instance on that port. After that I configured collabra using linux packages and a virtualhost config like this

cat /etc/apache2/sites-enabled/collaboraonline.charleswright.co-ssl.conf

<VirtualHost *:8443>
ServerAdmin email.redacted
ServerName collaboraonline.charleswright.co
Include /etc/apache2/conf-available/coolwsd.conf
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/collaboraonline.charleswright.co/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/collaboraonline.charleswright.co/privkey.pem

I can provide more details if needed, but mostly I just followed https://sdk.collaboraonline.com/docs/installation/Installation_from_packages.html#the-installation-procedure
Basically I've got only 1 IP address, so I use 80/443 for something else so I have to use nextcloud on another port. Recently I noticed the built-in code didn't start so I wanted to improve that. Seems at the moment I'm stuck until the port is functioning again.

[juliusknorr]

The URL that is used is determined by what the Collabora server reports back in its /hosting/discovery response. It might be that your reverse proxy is not handing the request host to that.

You could manually specify that in the coolwsd.xml config as server_name to include your port: https://github.com/CollaboraOnline/online/blob/master/coolwsd.xml.in#L41

Once configured you can verify that the XML returned by https://yourcollabora/hosting/discovery returns the correct URL.

[wrighrc]

@juliusknorr Thanks! I set the server_name but not the port in the file, now its working when I set the port!

[elzody]

@AdminMgl @SimeonEhrig Can you both also try what Julius suggested above and check your reverse proxy / web server configurations. Again, I can't reproduce, so it makes me think it is more a configuration issue -- can you confirm?

[SimeonEhrig]

@elzody I tried to check Julius suggestion. In preparation of it I configure everything like before the bug appears and now it simply works. So it means I simply setup the container with environment variables and configure a collabora URL in Nextcloud with non default port (19443). The coolswsd.xml is generated by the container.

My current versions are:

PHP version:
php8.2.7
Nextcloud version:
30.0.4
Version of the richdocuments app
8.5.3
Version of Collabora Online
24.04.11.1

I use the container images collabora/code:latest and nextcloud:30 together with an apache2 (2.4.58) as reverse proxy.