TYPO3 Core

OK I add a new configuration value and changed SSL detection in t3lib_div in this way:

if (!strcmp(trim($GLOBALS['TYPO3_CONF_VARS']['BE']['checkSSLProxy']),'1') && isset($_SERVER['HTTP_X_FORWARDED_HOST'])) {
return true;
}
elseif (strcmp(trim($GLOBALS['TYPO3_CONF_VARS']['BE']['checkSSLProxy']),'0') && $GLOBALS['TYPO3_CONF_VARS']['BE']['checkSSLProxy']==$_SERVER['HTTP_X_FORWARDED_SERVER']) {
return true;
}
else {
return $HTTP_SERVER_VARS['SSL_SESSION_ID'] || !strcmp($HTTP_SERVER_VARS['HTTPS'],'on') ? TRUE : FALSE;
}

Can you make a patch of this?

What exactly does the environment variable HTTP_X_FORWARDED_SERVER contain?

According to google the only resources where that env variable is named in a TYPO3 context are the following:
http://typo3.org/1427+M52c2ed2fff0.0.html?&tx_maillisttofaq_pi1%5Bpointer%5D=11
http://typo3.toaster-schwerin.de/mailarchive/msg16384.html

I don't think this should go into 3.7, I still remember the fuss about the bug in the SSL detection code in 3.6.0... So it might not be wise to give this patch so few time for testing.

OK I will explain it exactly:
an SSL key for a webserver is only attached to one domain
as I know it is very difficult (perhaps impossible) to configure apache in the way that each virtual domain has an own ssl key....

The solution is "ssl proxy" it works like:
the webserver has one ssl key, say for domain https://www.secureconnetion.com/
but the server handled much virtual domains like www.domain1.com
- if you call https://www.domain1.com/ the SSL key did not match the domain
- SSL Proxy means you can access domain1.com for example with the secure connection https://www.secureconnection.com/domain1.de/
- in most cases it is implemented with a simple mod_rewrite on the server , an example is attached

-------------------------------
Because people want to access TYOP3 Backend through SSL but have SSL-Proxy behavior on here server I submitted the patch:
(TYPO3 "thinks" the connection with SSL Proxy is unsecure, and so the SSL check fails and the reported behavior above appears...)

With the patch it is possible to access BE through such a secure connection, which is impossible now.

(the var HTTP_X_FORWARDED_SERVER is only set if the connection is through SSL-Proxy or something like that)

- the new configuration var "checkSSLProxy" can be 1 which means the SSL check returns true if HTTP_X_FORWARDED_SERVER is set (no matter what)
- if checkSSLProxy is something like "www.ssldomain.com" the ssl check returns true if HTTP_X_FORWARDED_SERVER is the same.

I tested it on my server ( 1und1 rootserver) and it works in both cases for this serverconfiguration.

If you aggree with it, how can I make a patch :-(

Beside why should it not go in 3.7:
If the configuration var is set to '0' or is empty nothing is changed in SSL detection?

bearbeitet am: 19.09.04 19:17

Daniel, your patch is still missing.

After a short discussion we have decided to not include this in 3.7.0. I want to try to reproduce this first and then test the solution locally. Hopefully it will go into 3.7.1.

(Sorry time was rar.)
Hope the attached patches are ok.
Greetings

I found a problem on some servers where "lockSSL = 2" would result in an endless loop and "lockSSL" redirects to an unsecure connection after login.
The problem is in the following line in t3lib:div.php:

$HTTP_SERVER_VARS['SSL_SESSION_ID'] || !strcmp($HTTP_SERVER_VARS['HTTPS'],'on') ? TRUE : FALSE;

This checks for HTTPS to have the value "on", however on the servers I use (managed servers from 1&1 and Schlund) the variable is "1" instead of "on". Changing the line accordingly fixes the problem.
I suggest to change the above line to check for either "on" or "1"

Jochen

At the current release 3.8.1 the problem is still not solved. Please solve this wih one of the two solutions. The solution of Jochen works well at the server I had to install. Thanks a lot.

see bug 1699 to get the correct paths ;-)

The patches attached to this bug report may fix the cases of SSL detection behind reverse proxies, but does not fix any of the more general reverse proxy bugs in Typo3 like e.g. #14229 or #14229.

IMHO there should be general feature to detect if Typo3 sits behind a reverse proxy (perhaps also via configuration), to get links, javascript and cookies work with the reverse proxies, not the backend Typo3 server.

I just uploaded an up-to-date patch to bug 1699 that also includes the code of the t3lib_div_diffs in this bug. See my comment there - and feel free to help ;-)

keyword:t3dd06

Hi,

I would like to help on solving the related bugs 169, 1699 and 202. Regarding the reverse proxy capabilities (including SSL) I have started to write a tutorial. The work on this tutorial is necessary for me to understand the problem in depth.

I hope it is also helpful for solving this issue and finding a solution that can be part of the core.

http://www.henningpingel.de/TYPO3-Backend-Via-SSL-Proxy.124.0.html

Best regards,
Henning

Please check out if the patch in #18126 will fix the problem.

duplicate according to Christian Kuhn