Setting use_https to true does has not the desired effect. The created URL now contains the scheme "https", but it still uses port 80. Other parts of the application now complain about errors like this one:

GET https://webmail.xxx.eu:80/chwala//skins/default/images/mimetypes/style.css net::ERR_SSL_PROTOCOL_ERROR

https is fine, but not at port 80.

Thank you for the fix, but it doesn't seem to work :-/

I've patched the few lines into my code, but the problem persists. The console says:

:80/chwala//skins/default/images/mimetypes/style.css Failed to load resource: net::ERR_SSL_PROTOCOL_ERROR

I've not forgotten to copy scheme and hostname - the part is really missing.

Another error in the console:

files_api.js Failed to load resource: net::ERR_SSL_PROTOCOL_ERROR

The file_api.js points to https://webmail.xxx.eu:80/chwala//js/files_api.js

Btw. I've cleared the browser cache to ensure that it does not contain any old fs-files.

UPDATE:
After I set the following

$config['kolab_files_url'] = 'https://webmail.xxx.eu/chwala/';

... I could see the file manager overview again, but opening a text file in an external window fails now with...

about:blank:1 Mixed Content: The page at 'https://webmail.xxx.eu/MxOfzbZ3ju9WILls/?_task=files&_action=open&_file=Files%2Ftest.txt&_viewer=6&_extwin=1' was loaded over HTTPS, but requested an insecure resource 'http://webmail.xxx.eu/chwala/api/?method=file_get&file=Files%2Ftest.txt&token=e5mlftc1idmc3oa6c96makerp6&viewer=text'. This request has been blocked; the content must be served over HTTPS.

What if you replace $_SERVER['SERVER_NAME'] with $_SERVER['HTTP_HOST']?

The other error comes from https://github.com/roundcube/roundcubemail/blob/master/program/lib/Roundcube/rcube_utils.php#L1121 that also should get the same port fix as in my last commit to chwala.

Hmm... I'm just thinking. Maybe in your env you don't have $_SERVER['SERVER_PORT'] set either. Then try replacing this with $_SERVER['HTTP_PORT'].

Forget my last comment. There's no such thing like $_SERVER['HTTP_PORT'].

Maybe you just applied the patch incorrectly. Note the dot character in this line:

$url .= ':' . $_SERVER['SERVER_PORT'];

I've done just copy & paste. The code of the resulting function is ...

/**
 * Returns API URL
 *
 * @return string API URL
 */
public function api_url()
{
    $api_url = $this->config->get('file_api_url', '');

    if (!preg_match('|^https?://|', $url)) {
        $schema = rcube_utils::https_check() ? 'https' : 'http';
        $port   = $schema == 'http' ? 80 : 443;
        $url    = $schema . '://' . $_SERVER['SERVER_NAME'];

        if ($_SERVER['SERVER_PORT'] != $port && $_SERVER['SERVER_PORT'] != 80) {
            $url .= ':' . $_SERVER['SERVER_PORT'];
        }

        if ($api_url) {
            $api_url = $url . '/' . trim($api_url, '/ ');
        }
        else {
            $url .= preg_replace('/\/?\?.*$/', '', $_SERVER['REQUEST_URI']);
            $url = preg_replace('/\/api$/', '', $url);

            $api_url = $url . '/api';
        }
    }

    return rtrim($api_url, '/ ');
}

I've written out $_SERVER['SERVER_PORT'] ... it's port 80. I assume that rcube_utils::https_check() returns true, so $schema is "https", this leads to $port = 443 and to a true, when evaluating the new if-block. So the port is appended to the hostname.

I don't see how $_SERVER['SERVER_PORT'] == 80 would make it appended to the url. The if statement requires it to be different than $port and than 80. Maybe we should use intval($_SERVER['SERVER_PORT']).

Ok, try this change: rCd0539d6f029d.

Now the error is away. Thank you!

Only the mixed-content error in the console keeps me from being really happy now.

Mixed Content: The page at 'https://webmail.xxx.eu/fY8DXdCkPLcrDOHf/?_task=files&_action=open&_file=Files%2Ftest.txt&_viewer=6&_extwin=1' was loaded over HTTPS, but requested an insecure resource 'http://webmail.xxx.eu/chwala/api/?method=file_get&file=Files%2Ftest.txt&token=hpf5ceu0mrd3kekfq5j85ljrv3&viewer=text'. This request has been blocked; the content must be served over HTTPS.

And that is with use_https=true? BTW, there's another fix: rC0349c2d84661.

Yes, I've set use_https to true and applied the mentioned fixes. I'm sorry, but the issue persists :-/

But it should work if you set file_api_url to a full url with https:// prefix? Do you set options in /etc/roundcubemail/config.inc.php? I'm unable to reproduce.

I've set in kolab_files.inc.php

$config['kolab_files_url'] = 'https://webmail.xxx.eu/chwala/';

Now I've additionally set in config.inc.php

$config['file_api_url'] = 'https://webmail.xxx.eu/chwala/';

Still the same issue.

Update:
What options do you mean?

Is there anything I can do to help you to diagnose it?

In this case it is Roundcube connecting to Chwala directly. It looks like the config has been ignored. I have no idea how's that possible. Maybe there's something in between that caches the request and returns old response? Check with a different file.

I've created a new text file and tried to open it. Same issue :-(

I've changed the file_api_url setting to some nonsense for testing purposes... Of course, it does not work, but the changed URL is passed along.

Update:
The error is

Mixed Content: The page at 'https://webmail.xxx.eu/h0BdpINBmfYSahkM/?_task=files&_action=open&_file=Files%2Fmytest.txt&_viewer=6&_extwin=1' was loaded over HTTPS, but requested an insecure resource 'http://webmail.xxx.eu/chwala/?method=file_get&file=Files%2Fmytest.txt&token=da6eb52fkecbp1godmldfm12r6&viewer=text'. This request has been blocked; the content must be served over HTTPS.

Can you tell me where the second URL in the error message gets crafted?

https://git.kolab.org/diffusion/C/browse/master/lib/viewers/text.php;0349c2d846613e4c828ed6f7af00b87ed6a75f79$120

As far as I can trace the calls back... our old friend api_url() is used to create the base URL and the scheme depends only on rcube_utils::https_check() and nothing else.
If the scheme "http" is used this can only mean, that rcube_utils::https_check() returned false - please correct me, if I'm wrong. Perhaps we should have a look at it next.

I've replaced the https_check() function with

public static function https_check($port=null, $use_https=true)
{
    return true;
}

... the created URL still contains "http". It's getting really strange now ;-)