[TYPO3-dev] Reinventing getIndpEnv() to support reverse proxys + SSL proxys

[Henning Pingel]

Hi Masi,

On my local harddisc I'm experimenting with a bunch of homebrew
configuration variables for reverse proxy support. This is I think the
least amount of configuration we need to support reverse and ssl proxys
properly:

$TYPO3_CONF_VARS['SYS']['revProxy_approveProxyRequests'] = true;
$TYPO3_CONF_VARS['SYS']['revProxy_useHTTPS'] = true;
$TYPO3_CONF_VARS['SYS']['revProxy_forceBackendAccessViaProxy'] = true;
$TYPO3_CONF_VARS['SYS']['revProxy_limitUserAccessByIP'] = true;
$TYPO3_CONF_VARS['SYS']['revProxy_validUserIPs'] = '123.123.123.123';
$TYPO3_CONF_VARS['SYS']['revProxy_validProxyHostNameList'] =
  'proxy1.tld, proxy2.tld, proxy3.tld';
$TYPO3_CONF_VARS['SYS']['revProxy_validProxyIPList'] =
  '192.168.1.111, 192.168.1.112, 192.168.1.113';

This is just to show that I think finding a general solution for reverse
and SSL proxys is quite complex and likely to be buggy.

But we could of course say, that a first solution for proxy support will
only work with one reverse proxy, not with more than one. This will
simplify things a little bit.

Am 16.02.2008 16:14 schrieb Martin Kutschker:
> PS: BTW, you don't need a hook for that. I have written an extension
> that modifies the environment itself. If you change localconf.php so
> that it is loaded very early TYPO3 won't ever see the original
> environment. This trick worked well in my 2 current proxy installations.

Wow! That is of course a sneaky idea, and I have to admit that this idea
didn't turn up in my head. This also fixes compatibility issues of those
extensions where the authors use $_SERVER directly instead of
getIndpEnv(). So the extension authors don't have to be bothered with
this then.

But I think it has one big drawback: The extension authors don't have to
be bothered with this then. ;-) Imagine, many people use reverse proxys
and there are lot's of extensions that don't work any more, this may
mean the opportunity to put pressure on extension authors to write their
code according to the CGLs. At some point then we could afford to have
something like this in the core after all interesting values have be
preserved by getIndpEnv:

	$_SERVER = NULL;

This would also be good for security reaons, because we could do some
centralized security checks for illegal values (XSS, etc.) within the
values of $_SERVER that are in control of the user, for example
HTTP_USER_AGENT.

Cheers,
Henning