Bug #15135

Typo3 backend does not work with reverse proxy

Added by Christian Boltz over 11 years ago. Updated over 8 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


I'd like to use Typo3 through a reverse proxy. This means the following entries in the Apache config for host foo.test:

ProxyPass /bar.test http://bar.test
ProxyPassReverse /bar.test http://bar.test

The result is that I can access http://bar.test as http://foo.test/bar.test/
This sounds not very useful yet, but as soon as you replace http with https and have lots of vHosts on one IP it becomes really interesting. You could access the Typo3 backends on all vHosts via https and avoid sending unencrypted passwords over the net this way...

Unfortunately, the Typo3 backend uses absolute links in the menu, so when clicking "Page" in https://foo.test/bar/test/alt_main.php, it tries to load https://foo.test/typo3/alt_mod_frameset.php?... which can obviously not be found (/bar.test/ is missing in the URL).

I'm afraid there are more absolute links "deeper" in the backend, but I can't test it as long as the menu doesn't work :-(

It would be really great if the backend menu (and all other parts of Typo3) would use relative instead of absolute links.

If this can't be done in the next future, a config option "always prepend path:" would be nice.

(issue imported from #M1699)

typo3-sslproxy.patch View (5.4 KB) Administrator Admin, 2005-12-19 17:44

2006-01-18-typo3-sslproxy.patch View (4.92 KB) Administrator Admin, 2006-01-18 23:45

Related issues

Related to Core - Bug #14210: SSL - SSL Lock HTTPS Proxy ... Resolved 2004-06-17
Related to Core - Feature #14229: Typo3 doesn't support Proxing like Zope for instance Closed 2004-07-06
Duplicates Core - Bug #18126: Proxy servers replace REMOTE_ADDR with their own IP Closed 2008-02-05


#1 Updated by Christian Boltz over 11 years ago

I don't think #15146 and #15146 are related.
Yes, they both talk about reverse proxies, but
- #15146 is about load balancing and seems to be related to a sesion problem IMHO
- #15146 is about wrongly generated URLs because of different paths in server's / browser's point of view
These are two completely different things ;-)

#2 Updated by Christian Boltz over 11 years ago

I spent some hours to locate the problem. Here's a summary:

The reason why it is not working:
from typo3/alt_main.php, line 158-160 (generated JavaScript)

function typoSetup()    {   //
this.PATH_typo3 = "'.$pt3.'";
this.PATH_typo3_enc = "'.rawurlencode($pt3).'";

PATH_typo3 and PATH_typo3_enc should be prefixed with the reverse proxy "alias" (/bar.test/ in my example).

When I change this, the menu is working. I also can edit pages, but not save them - path issue again.

typo3/alt_doc.php, line 189 (later used for <form action=...>:

$this->R_URL_parts = parse_url(t3lib_div::getIndpEnv('REQUEST_URI'));

How to fix it:
After further investigation, I found that all the URL things come from typo3/t3lib/class.t3lib_div.php, function getIndpEnv. It shouldn't be too hard to add a prefix to the relevant $getEnvName.

"Relevant" $getEnvName keys are IMHO (please correct me if I'm wrong):

I'm not sure about TYPO3_SITE_URL because of "PATH_thisScript" and "PATH_site" - but I'm afraid it needs to be prefixed too. (I hope PATH_thisScript and PATH_site theirself don't need to be modified because they are set before localconf.php is included.)

TYPO3_REQUEST_URL, TYPO3_REQUEST_SCRIPT, TYPO3_REQUEST_DIR and TYPO3_SITE_SCRIPT use recursive calls of this function, so they should (IMHO) "inherit" the changes from REQUEST_URI and SCRIPT_NAME.

Where to get the prefix?
The prefix could be set in localconf.php:
$TYPO3_CONF_VARS['BE']['ReverseProxyPrefix']) = "/bar.test";
(just as a variable name suggestion ;-)

Autodetecting the required prefix would be nice, but I guess it would be much more work than setting a variable in localconf.php ;-)

#3 Updated by Sebastian Kurfuerst over 11 years ago

Hi Christian,
is it possible for you to upload a patch which implements the desired behavior? This would be very helpful.
Greets, Sebastian

#4 Updated by Christian Boltz over 11 years ago

The attached patch solves a large portion of this bug:
- it has a autodetection if you are connecting via SSL-Proxy or normal http (works at least on my Apache 2.0 server)
- all links in the backend work

Please add the following to your localconf.php to make it working:
$TYPO3_CONF_VARS['BE']['ReverseProxyServer'] = "ssl.myserver.com";
$TYPO3_CONF_VARS['BE']['ReverseProxyDirectory'] = "/bar.test";

You can now access Typo3 using http://bar.test and https://ssl.myserver.com/bar.test.

The only thing that doesn't work right now is saving or closing a content element - it always misses the /bar.test prefix in the returnUrl and the path itsself. I always get
but would need an additional "%2Fbar.test" in returnUrl and an additinal "/bar.test" in front of the url:

What do I need to change to make this working?

BTW: How can I set the bug state back from "Rückmeldung" (needinfo) to assigned?

PS: I know that my code is not very "clean" - but let's make it working first, I will clean up then ;-)

#5 Updated by Axel Beckert over 11 years ago

This is also related to Bug Id #14229: http://bugs.typo3.org/view.php?id=202

#6 Updated by Christian Boltz over 11 years ago

Oh, I forgot: My patch is built against Typo3 3.8.1

#7 Updated by Christian Boltz over 11 years ago

"I just found that bug 169 is about the same problem - and it has a more elegant (and mostly working ;-) patch than mine."

This is what I thougt, but it seems I used my modified version to test the patch from bug 169 :-( After testing with a fresh install, it didn't work.

In short:
- you still need my patch to get the correct paths
- saving changes still doesn't work (because of a hardcoded path, I guess) :-(

#8 Updated by Axel Beckert over 11 years ago

Please note, that the patches attached to #14210 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. #14210 or this one.

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.

The patch attached to this bug seems to go into the right direction, but I currently haven't the overview to be able to evaluate the patch. Our local solution currently is to allow the customers direct access to the backend server for the Typo backend while their customers use the frontend via the reverse proxies. Ugly, but works fine where the reverse proxy reason is not SSL, but e.g. performance.

#9 Updated by Christian Boltz over 11 years ago

I just uploaded an up-to-date patch (2006-01-18*) for Typo3 3.8.1 that also includes code from the patch in bug 169. Please note that the TYPO3_SSL code works for me, but may be not correct.

Unfortunately the save and close icons still don't work which is my largest problem :-(
Can anybody help on this?

#10 Updated by Henning Pingel over 10 years ago


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.


Best regards,

#11 Updated by Christian Jul Jensen over 8 years ago

duplicate according to Christian Kuhn

Also available in: Atom PDF