TYPO3 Core

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 ;-)

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):
- REQUEST_URI
- SCRIPT_NAME
- TYPO3_SITE_URL (?)

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 ;-)

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

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
typo3/alt_doc.php?&returnUrl=%2Ftypo3%2Fsysext%2Fcms%2Flayout%2Fdb_layout.php%3Fid%3D1&edit[tt_content][2,]=edit
but would need an additional "%2Fbar.test" in returnUrl and an additinal "/bar.test" in front of the url:
/bar.test/typo3/alt_doc.php?&returnUrl=%2Fbar.test%2Ftypo3%2Fsysext%2Fcms%2Flayout%2Fdb_layout.php%3Fid%3D1&edit[tt_content][2,]=edit

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 ;-)

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

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

"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) :-(

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.

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?

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

duplicate according to Christian Kuhn