TYPO3 Core

Benni Mack wrote:

Are you using a proxy actually? Or are you using apache itself but not using "HTTPS=on"?

The latter: in our case Apache is not returning "HTTPS=on". So by checking the alternative variable that we do have, we now set the HTTPS=on using the .htaccess (see solution above).
However I heard from Andreas Fernandez in the Slack Typo3 channel (typo3-cms-backend-js) that Nginx doesn't set this variable by default either, so that might give similar problems.

I added some related issues to this one because there have already been discussions before. (Not exactly the same scenario but similar).

It is not clear to me: Why is the server variable HTTPS not set on your Apache httpd configuration? What speaks against setting it on the server side (as you are already doing)?

IMHO I would configure this on the server-side to the de facto HTTPS server variable. I would not add hooks and configuration variables unless really necessary but instead try to adhere to the standards or de facto standards.

As far as I know other CMSs also rely on the HTTPS variable and most info I found online goes in that direction. Newer Nginx versions apparently set it by default. If not, you can add it to the configuration very easily.

In any case, I think to comply with the PHP documentation the check could be changed to check if $_SERVER['HTTPS'] exists and is non empty (instead of checking if equals "on" or '1'). Except for the mentioned exception for IIS.

For example:

if ( ...  || (!empty($_SERVER['HTTPS'] && strtolower($_SERVER['HTTPS']) !== 'off'))

see docs:

"_'HTTPS'
Set to a non-empty value if the script was queried through the HTTPS protocol._

Note: Note that when using ISAPI with IIS, the value will be off if the request was not made through the HTTPS protocol."

(http://php.net/manual/en/reserved.variables.server.php)

Yes, that check would be perfect.

The reason we don't have the $_SERVER['HTTPS'] variable has to do with our loadbalancer rules in combination with a Varnish caching layer. These rules apply certain redirects based on this special X-ClientHTTPS variable because we have a couple of sites on the same IP.

Changing the check to your suggestion would be perfect. ;-)

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/55750

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/55750

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/55750

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/55750

Patch set 1 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/55764

We had a similar error that matched the behaviour exactly: "As a result, the Install tool is not accessible anymore and you can't use the close button when editting a record."

For the record, we could solve it without the patch using the following params

Disable Apache mod_remoteip

$GLOBALS['TYPO3_CONF_VARS']['SYS']['reverseProxyIP'] = '127.0.0.1';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['reverseProxyHeaderMultiValue'] = 'last';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['reverseProxySSL'] = '*';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] = 'www.mysite.com';

Caveat: this setting will move the client IP to HTTP_X_FORWARDED_FOR instead of REMOTE_ADDR in the request.