Too many Redirects when accessing Roundcube

Hi,

On my new Web- and Mailserver, based on Nethserver for sure, I am trying to accessing the Roundcube Website but I fail in “Too many redirects”-Error. This only happens, if I am accessing the site via DNS Name (https://something.com/webmail). If I am using the internal IP address from an internal PC I have no problems with it. I am using Nethserver 7 with all updates installed.
Any Ideas how I can figure out what is causing the endless-redirects?

Edit:
One more information: if I am just accessing http(s)://something.com I have no problems.

Edit2:
And one more information. Maybe it has something to do with it. I have a Virtual host configured to answer the something.com-Domain like this:


And after one more test I belive the Problem is here. Because: If I am accessing a subdomain I registered (mail.*) with the /webmail-Suffix, it works:

In both cases (with or without the “mail.” in front) the same IP is resolved and directed to the Nethserver. The difference is that the mail.-Subdomain has no Virtual Host.
Maybe it is a Bug?

1 Like

Anyone can help here? Is there a config I can check? Where are this kind of redirections configured?

Thank you @Hunv for your report. It might be a bug but now I can’t try to reproduce it!

It would be good to read the output from curl command instead of screenshoots :wink:

curl -v -k https://<whatever>/webmail

It should be repeated on different URLs to see what the web server replies…

1 Like

Hi, this is the output of the command (dummies at IP and DNS):

curl.exe -v -k https://something.com/webmail
*   Trying 12.23.34.56...
* TCP_NODELAY set
* Connected to something.com (12.23.34.56) port 443 (#0)
* schannel: SSL/TLS connection with something.com port 443 (step 1/3)
* schannel: disabled server certificate revocation checks
* schannel: verifyhost setting prevents Schannel from comparing the supplied target name with the subject names in server certificates. Also disables SNI.
* schannel: sending initial handshake data: sending 195 bytes...
* schannel: sent initial handshake data: sent 195 bytes
* schannel: SSL/TLS connection with something.com port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with something.com port 443 (step 2/3)
* schannel: encrypted data buffer: offset 1826 length 4096
* schannel: sending next handshake data: sending 126 bytes...
* schannel: SSL/TLS connection with something.com port 443 (step 2/3)
* schannel: encrypted data buffer: offset 274 length 4096
* schannel: SSL/TLS handshake complete
* schannel: SSL/TLS connection with something.com port 443 (step 3/3)
* schannel: stored credential handle in session cache
> GET /webmail HTTP/1.1
> Host: something.com
> User-Agent: curl/7.50.3
> Accept: */*
>
* schannel: client wants to read 16384 bytes
* schannel: encdata_buffer resized 17408
* schannel: encrypted data buffer: offset 0 length 17408
* schannel: encrypted data got 555
* schannel: encrypted data buffer: offset 555 length 17408
* schannel: decrypted data length: 250
* schannel: decrypted data added: 250
* schannel: decrypted data cached: offset 250 length 16384
* schannel: encrypted data length: 276
* schannel: encrypted data cached: offset 276 length 17408
* schannel: decrypted data length: 247
* schannel: decrypted data added: 247
* schannel: decrypted data cached: offset 497 length 16384
* schannel: encrypted data buffer: offset 0 length 17408
* schannel: decrypted data buffer: offset 497 length 16384
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 497
* schannel: decrypted data buffer: offset 0 length 16384
< HTTP/1.1 301 Moved Permanently
< Date: Fri, 02 Dec 2016 17:17:51 GMT
< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.4.16
< Location: http://something.com/webmail/
< Content-Length: 247
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://something.com/webmail/">here</a>.</p>
</body></html>
* Curl_http_done: called premature == 0
* Connection #0 to host something.com left intact
1 Like

Please try also by adding the -L flag

curl -L ...

We should see the loop…

1 Like

Yes, correct. I see a loop with this content:

* Curl_http_done: called premature == 0
* Connection #0 to host something.com left intact
* Issue another request to this URL: 'https://something.com/webmail/'
* Found bundle for host something.com: 0x2817c9724f0 [can pipeline]
* Re-using existing connection! (#0) with host something.com
* Connected to something.com (12.23.34.56) port 443 (#0)
> GET /webmail/ HTTP/1.1
> Host: something.com
> User-Agent: curl/7.50.3
> Accept: */*
>
* schannel: client wants to read 16384 bytes
* schannel: encrypted data buffer: offset 0 length 17408
* schannel: encrypted data got 612
* schannel: encrypted data buffer: offset 612 length 17408
* schannel: decrypted data length: 583
* schannel: decrypted data added: 583
* schannel: decrypted data cached: offset 583 length 16384
* schannel: encrypted data buffer: offset 0 length 17408
* schannel: decrypted data buffer: offset 583 length 16384
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 583
* schannel: decrypted data buffer: offset 0 length 16384
< HTTP/1.1 302 Found
< Date: Fri, 02 Dec 2016 17:23:52 GMT
< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.4.16
< X-Powered-By: PHP/5.4.16
< Set-Cookie: roundcube_sessid=lhaemlb844t2ks74ou8o7ng8k4; path=/; HttpOnly
< Expires: Fri, 02 Dec 2016 17:23:52 GMT
< Cache-Control: private, no-cache, no-store, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Last-Modified: Fri, 02 Dec 2016 17:23:52 GMT
< X-DNS-Prefetch-Control: off
< X-Frame-Options: sameorigin
< Location: https://something.com/webmail/
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
<
* Curl_http_done: called premature == 0
* Connection #0 to host something.com left intact
* Issue another request to this URL: 'https://something.com/webmail/'
* Found bundle for host something.com: 0x2817c9724f0 [can pipeline]
* Re-using existing connection! (#0) with host something.com
* Connected to something.com (12.23.34.56) port 443 (#0)
> GET /webmail/ HTTP/1.1
> Host: something.com
> User-Agent: curl/7.50.3
> Accept: */*
>
* schannel: client wants to read 16384 bytes
* schannel: encrypted data buffer: offset 0 length 17408
* schannel: encrypted data got 612
* schannel: encrypted data buffer: offset 612 length 17408
* schannel: decrypted data length: 583
* schannel: decrypted data added: 583
* schannel: decrypted data cached: offset 583 length 16384
* schannel: encrypted data buffer: offset 0 length 17408
* schannel: decrypted data buffer: offset 583 length 16384
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 583
* schannel: decrypted data buffer: offset 0 length 16384
< HTTP/1.1 302 Found
< Date: Fri, 02 Dec 2016 17:23:52 GMT
< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.4.16
< X-Powered-By: PHP/5.4.16
< Set-Cookie: roundcube_sessid=sf2b5ah79md7kau1vkr9eoak44; path=/; HttpOnly
< Expires: Fri, 02 Dec 2016 17:23:52 GMT
< Cache-Control: private, no-cache, no-store, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Last-Modified: Fri, 02 Dec 2016 17:23:52 GMT
< X-DNS-Prefetch-Control: off
< X-Frame-Options: sameorigin
< Location: https://something.com/webmail/
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
<
* Curl_http_done: called premature == 0
* Connection #0 to host something.com left intact
* Issue another request to this URL: 'https://something.com/webmail/'
* Found bundle for host something.com: 0x2817c9724f0 [can pipeline]
* Re-using existing connection! (#0) with host something.com
* Connected to something.com (12.23.34.56) port 443 (#0)
> GET /webmail/ HTTP/1.1
> Host: something.com
> User-Agent: curl/7.50.3
> Accept: */*
1 Like

What is the result of the issue that we know that there is a loop? I have absolutly no idea how I can investigate the reason for it. I checked the apache configs but I don’t see a reason in there why here is a loop like this. Any suggestions or ideas how to go on?

Installed Roundcube to test this and encountered the same problem when using a virtualhost.
No difference when updating packages from testing repo.

Using curl what changes in each redirected request is the cookie:

Set-Cookie: roundcube_sessid=lhaemlb844t2ks74ou8o7ng8k4; path=/; HttpOnly

Don’t ask me why but it works when editing /etc/roundcubemail/config.inc.php

// enforce connections over https
// with this option enabled, all non-secure connections will be redirected.
// set the port for the ssl connection as value of this option if it differs from the default 443
$config[‘force_https’] = false; // originally set to true

// tell PHP that it should work as under secure connection
// even if it doesn’t recognize it as secure ($_SERVER[‘HTTPS’] is not set)
// e.g. when you’re running Roundcube behind a https proxy
// this option is mutually exclusive to ‘force_https’ and only either one of them should be set to true.
$config[‘use_https’] = true; // originally set to false


Other errors:

[autoindex:error] [pid 6609] [client 192.168.25.13:52776] AH01276: Cannot serve directory /var/lib/nethserver/vhost/testvhost/: No matching DirectoryIndex (index.html,index.php) found, and server-generated directory index forbidden by Options directive

Probably unrelated, but this error showed up when expanding-templates:

esmith::event[3259]: ERROR in /etc/e-smith/db/networks/migrate//trafficshaping.el7: Program fragment delivered error <<Can’t call method “delete” on an undefined value at /etc/e-smith/db/networks/migrate//trafficshaping.el7 line 22.>> at template line 1
esmith::event[3259]: ERROR: Template processing failed for /: 1 fragment generated errors
esmith::event[3259]: at /usr/share/perl5/vendor_perl/esmith/DB.pm line 459.

3 Likes

@dnutan Great work :+1:
So we have a workaround for it and we know that it is a common problem and not only my problem that should be fixed until the release of NS7.

1 Like

I can reproduce the bug but I’m not sure about the fix.

My environment:

Tests with force_https = true and use_https = false

Tests with force_https = false and use_https = true

I’ve tried several combinations but I didn’t find one which behaves correctly in all cases.

What do you think? I see two scenarios:

  1. roundcubemail works correctly (http redirect to https) only on FQDN
  2. roundcubemail works correctly on any virtualhost but not on FQDN (no http redirect to https)

(I prefer the first one :wink: )

3 Likes

:thumbsup: me too!

If I want a name virtual host to publish roundcube I make a custom config and remove the webmail/ path.

If I want webmail/ I don’t define a name virtualhost, and fall back to default vhost.

My bad, I didn’t drive attention towards the http -> https redirection issue.
I also prefer the first option for the FQDN to prevail.

In addition to the roundcube config changes, yesterday tried an additional change, this time on /etc/httpd/conf.d/default-virtualhost.inc file, removing the \ escape chars:

RewriteEngine On
RewriteRule ^/webmail(/.*)?$ https://%{HTTP_HOST}/webmail$1 [R=301,L]
RewriteRule ^/roundcubemail(/.*)?$ https://%{HTTP_HOST}/roundcubemail$1 [R=301,L]

And the http to https worked with the FQDN and with the virtualhost.
Bear in mind I’ve no clue neither about rewrite rules nor vhosts, so if this is wrong… shame on me.:blush:


P.S. with other virtual hosts redirections (i.e. /server-manager) it’s looking for it on /var/lib/nethserver/vhost/whatever/server-manager, which might be the expected behavior.

[details=See log excerpt]

[ssl:debug] Connection closed to child 6 with standard shutdown (server pippo.org:80)
[rewrite:trace2] init rewrite engine with requested uri /server-manager
[rewrite:trace3] applying pattern ‘(.)’ to uri ‘/server-manager’
[rewrite:trace4] RewriteCond: input=‘off’ pattern=’!=on’ => matched
[rewrite:trace2] rewrite ‘/server-manager’ -> ‘https://pippo.org/server-manager
[rewrite:trace2] explicitly forcing redirect with https://pippo.org/server-manager
[rewrite:trace1] escaping https://pippo.org/server-manager for redirect
[rewrite:trace1] redirect to https://pippo.org/server-manager [REDIRECT/302]
[ssl:debug] Connection closed to child 0 with standard shutdown (server pippo.org:80)
[ssl:debug] HTTPS request received for child 4 (server pippo.org:80)
[rewrite:trace2] init rewrite engine with requested uri /server-manager
[rewrite:trace3] applying pattern '(.
)’ to uri ‘/server-manager’
[rewrite:trace4] RewriteCond: input=‘on’ pattern=’!=on’ => not-matched
[rewrite:trace1] pass through /server-manager
[authz_core:debug] AH01626: authorization result of Require ip 127.0.0.1 192.168.0.0/255.255.255.0: granted
[authz_core:debug] AH01626: authorization result of : granted
[authz_core:debug] AH01626: authorization result of : granted
[core:info] AH00128: File does not exist: /var/lib/nethserver/vhost/pippo/server-manager
[ssl:debug] AH02001: Connection closed to child 4 with standard shutdown (server pippo.org:80)
[/details]
2 Likes

Removing the \ in front of the $ is a correct bugfix I think.
Why?
The whole string looks like RegEx (except that the / is not escaped).
The $ would mean “Dollar Character”.
Only $ would mean “End of String”.
So the whole part ^/webmail(/.*)?$ means
^ = String starts here
/webmail = followed by the string “/webmail
/.* = followed by any characters between count of zero and unlimited
? = the statement before (/.*) can be zero or one time

Check by yourself at www.regex101.com and paste ^\/webmail(\/.*)?$ (with correctly escaped slashes).

Additionally the second rule in that files, as @dnutan mentioned, don’t have the escaped $.

WRONG AFTER EDIT:

As a result it sounds reasonable for me, that the remove of the \ is the solution.

Edit:
After I removed the \ at the end of the first and the second RegEx Statement and executed signal-event nethserver-httpd-update I still have the same problem…
The file I modified was /etc/e-smith/templates/etc/httpd/conf.d/default-virtualhost.inc/30roundcubemail and the change is also available in /etc/httpd/conf.d/default-virtualhost.inc after the signal event

2 Likes

cc @Hunv

Yes you are right!
Struggled with the escape charters making the sogo virtualhost.inc; It’s not needed before the $ here.

@Hunv, the changes I made just for testing where in /etc/httpd/conf.d/default-virtualhost.inc.
If the changes are applied to the e-smith template then some additional escaping could be required.

But without additional escaping the resulting virtualhosts.inc looks good.

1 Like

In the template you need to escape the { and } , other wise e-smith thinks a perl statement is comming up.

Try this in the template:

RewriteEngine On
RewriteRule ^/webmail(/.*)?$ https://%\{HTTP_HOST\}/webmail$1 [R=301,L]
RewriteRule ^/roundcubemail(/.*)?$ https://%\{HTTP_HOST\}/roundcubemail$1 [R=301,L]

Edit: tip always look in the message log to check a template is expanded successful

2 Likes

Applied the changes proposed by Mark, in a custom template. The resulting file looks good, no expansion error in the log.

A recap. There were two workarounds involved:

  • For the too many redirects (redirect loop) in roundcube: changes on /etc/roundcubemail/config.inc.php

      $config['force_https'] = false; //default was true. This change was the workaround
      $config['use_https'] = true; //default was false. Seemed unnecessary for the workaround, but was changed as adviced by the doc comments.
    
  • For the http to https redirection:

  • virtual host set to “Require SSL encrypted connection”

  • Change in rewrite rules (then template expansion, httpd restart)

Additionally, browser’s DNS cache was cleaned.

Maybe it’s not the proper fix, but worked in my tests when accessing from LAN, without proxy.

2 Likes

AFAIK, it’s a proper fix. :slight_smile: And Kudos to @Hunv

The package is ready for test:

Kudos to all for all the work, I’m really amazed! :smiley: