Am 08.02.2017 um 00:44 schrieb Yann Ylavic:
On Wed, Feb 8, 2017 at 12:25 AM, Yann Ylavic <ylavic....@gmail.com> wrote:
On Wed, Feb 8, 2017 at 12:01 AM, Reindl Harald <h.rei...@thelounge.net> wrote:
how can you trust as a php application developer that "X-Forwarded-Proto" is
trustable and not from the enduser client at all - for REMOTE_ADDR you don't
consider "X-Forwarded-For" exactly for that reason
I'm not proposing to use or trust "X-Forwarded-Proto" directly, but
that mod_remoteip [either directly or provides the (optional)
functions for ap_add_{common,cgi}_vars() to] set REMOTE_HTTPS=on
and/or REMOTE_SCHEME=https accordingly.
Just like REMOTE_ADDR.
But not change HTTPS and/or REQUEST_SCHEME (but more importantly their
sources/hooks as accessed and read by core/modules), like (IIUC)
proposed by the patches.
These are local informations.
Actually, I'm not really opposed to set HTTPS=on (according to
mod_remoteip) in the environment *given to the script/CGI* only, if
that's the trigger for it to do the desired thing, this won't be used
by httpd internally at least.
What's proposed so far is much more than that (if I read the patches correctly)
ok, so finally we agree :-)
i am only interested in a centralized way to get rid of hacks like below
in each and every application where mod_remoteip solves the similar
problem with $_SERVER['REMOTAE_ADDR'] for cgi/mod_php
$_SERVER['REQUEST_SCHEME'] because you typically build a full qualifiied
URL for a link in emails with $_SERVER['REQUEST_SCHEME'] . '//' .
$_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'] . '?param=x'
in my own application the hack below was simple - in case of other
software like Magento and so on you have to hack "index.php" while at
the same time you should not touch the application code to keep it
easily updateable
if(!empty($config['cms_tls_offload']))
{
$_SERVER['SERVER_PORT'] = '443';
$_SERVER['REQUEST_SCHEME'] = 'https';
$_SERVER['HTTPS'] = 'on';
}
