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" } } }

<details>
<summary>Logs</summary>

#### Nextcloud log (data/nextcloud.log)
Nothing.

#### Part of access.log

POST /browser/d5ebff5/cool.html?WOPISrc=https%3A%2F%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

</details>

[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.