Infinite loading bar / logon error message

[nextgen-networks]

Hello rotdrop,

maaaaaany, many thanks for your ongoing work on this plugin.

Here are the observations based on latest rc6.

Two possible configurations seem to have problems in different stages:

• First config - subdomain
  Seems to be stuck in a login/connect loop and showing a infinite loading bar.
  This is based on Roundcube delivered in subdomain of the nextcloud domain.
  

• Second config - subfolder
  This instance is proxied from a subolder (/roundcube) of nextcloud to another (sub)domain and got an error as below.
  

This is the proxy config example used to redirect the roundcube request:
location /roundcube/ {
proxy_pass https://sub.domain.tld/;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Any ideas how to solve either one of the above configurations?

Thank you very much.

[rotdrop]

Hi,

I will have a look. However, I was busy with converting the stuff to Vue and I'm also planning to add translation support by Transifex (not that there would be much to be translated ...)

I did not test the proxy thing yet. At home I have RC just in a sub-folder, and on the laptop both NC and RC in subfolders. I did not yet test the proxy configuration.

However, from other Proxy experiments I know that proxying can be tricky, as one might need to meddle with the HTML code returned by the proxied web-app.

We will see ....

[rotdrop]

I am just experimenting with Roundcube behind a proxy. This is of course only necessary when the RC installation is served by another web-server, otherwise a simple Alias directive does the trick and is much simpler.

So, first thing is to try to have a working proxy configuration independent from Nextcloud server. It just should work in the web-browser without embedding it in an IFrame element. If that works, one can continue and see if it also works in NC.

So first thing: I have no Nginx running. Trying to use RC behind an Apache proxy like so:

<Location /roundcube-proxy/>
    # Try to do the same with a proxy configuration
    ProxyPass https://webmail.mydomain.tld/
    ProxyPassReverse https://webmail.mydomain.tld/
    ProxyPreserveHost Off
</Locaation>

gives me the login-window. However, caused by recent changes:

roundcube/roundcubemail#8738

the form-action is then an absolute URL: /?_task=login. Ok, perhaps the Nextcloud app can work around this during login, by just posting to the proxy-address (I think it does), but this may also be the root of the problem with the empty mail view. If Roundcube now insists on absolute URL everywhere, then the proxy setup will just break, unless

1. one adds mod_proxy_html. However, after two hours I am still not at the point where this works. The following config is still not enough:

<Location /roundcube-proxy/>
    # Try to do the same with a proxy configuration
    ProxyPass https://webmail.mydomain.tld/
    ProxyPassReverse https://webmail.mydomain.tld/
    ProxyPreserveHost Off
    ProxyHtmlEnable On
    ProxyHtmlURLMap "^/(?!roundcube-proxy)" "/roundcube-proxy/" R
    SetOutputFilter INFLATE;proxy-html;DEFLATE
</Location>

Unfortunately, this gets one past the login-page, but the empty mail and the server error messages appear. I you have a mind to view the XHR request by RC with browser's developer tools then you will find that it is indeed still missing the proxy-prefix, and this is also hard to change: AJAX posts or probably generated dynamically by Javascript code, there is hardly a way to handle this with ProxyHtml.

2. one reads a little further and configures RC to use the (new?) config setting request_path:

// Specifies the full path of the original HTTP request, either as a real path or
// $_SERVER field name. This might be useful when Roundcube runs behind a reverse
// proxy using a subpath. This is a path part of the URL, not the full URL!
// The reverse proxy config can specify a custom header (e.g. X-Forwarded-Path) containing
// the path under which Roundcube is exposed to the outside world (e.g. /rcube/).
// This header value is then available in PHP with $_SERVER['HTTP_X_FORWARDED_PATH'].
// By default the path comes from 'REQUEST_URI', 'REDIRECT_SCRIPT_URL' or 'SCRIPT_NAME',
// whichever is set (in this order).
$config['request_path'] = null;

The second possibility seems to work by just adding

$config['request_path'] = '.';

which presumable simply installs the previous behaviour.

Bad news: if you have no access to the RC installation then this is not possible.

Ok, that was a long. Summary: the embedding in the iframe in principle works, but roundcube/roundcubemail#8738 also means that currently it does not work behind a proxy unless you change the configuration of the Roundcube installation.

That's it for the moment.

Best

Claus

[rotdrop]

Hi there, in principle I would schedule a first "real" app-store release next week. Perhaps you could confirm the thing with the Roundcube request_path setting. Or maybe you have ideas how to handle this in another way without having to adjust the Roundcube configuration ...

Best, Claus

[nextgen-networks]

Hey Claus,

many thanks for pinting out the request_path parameter!
After upgrading from roundcube 1.6.0 to 1.6.1 (parameter is introduced in that version) it works perfectly!

I think this issue can be closed :-)

[rotdrop]

Great! Thanks for testing at a weekend (I think that this thing is related to your pay-job, isn't ?)

I'll probably release a first "non experimental" (oh well) version 1.0.0 Monday or Tuesday.

[nextgen-networks]

No this is purely a hobby and I had been trying to get RC 1.6 back into Nextcloud for a very long time - but was unsuccessful.
So I couldn't wait to try your solution and am extremely happy that it works.
Now the Nextcloud on the community server as well as on the family server can be used again with a proper email integration.

Once again super big thanks for your great work!