PROJECT_URI should be configurable

[PascalTurbo]

I fought a hard fight installing Baikal in my environment. After some investigation I found, that the base-url is calculated. This is a very nice behavior if you use baikal directly on a vhost - but unusable if you have a load balancer in front of it - so do I. There has been multiple problems:

1. The communication between the LB and the Baikal vhost is unencrypted - the outside communication uses SSL
2. I don't care about fqdn inside the machine - so it is only known outside.

I think it should be possible to configure the base url in the global configuration file. If it's not configured the current behaviour would fitt.

[jmkeil]

PROJECT_BASEURI should also be configurable. Both depend on the same calculation. And both are source of problems during installation in some environments (see #30, #144, #147, #271, #361).
An other option would be to improve the calculation of PROJECT_BASEURI and PROJECT_URI. There are, as far as I know, 4 cases to consider. This are the 4 cases in the example of cal.php:

• DOCUMENT_ROOT as expected and no subfolder (only case currently working)

domain redirection: baikal1.example.com -> …/htdocs/baikal1/
DOCUMENT_ROOT: …/htdocs/baikal1/
SCRIPT_FILENAME: …/htdocs/baikal1/cal.php
REQUEST_URI: baikal1.example.com/cal.php/…

• unexpected DOCUMENT_ROOT and no subfolder

domain redirection: baikal1.example.com -> …/htdocs/baikal1/
DOCUMENT_ROOT: …/htdocs/
SCRIPT_FILENAME: …/htdocs/baikal1/cal.php
REQUEST_URI: baikal1.example.com/cal.php/…

• DOCUMENT_ROOT as expected and subfolder

domain redirection: baikal1.example.com -> …/htdocs/baikal1/
DOCUMENT_ROOT: …/htdocs/baikal1/
SCRIPT_FILENAME: …/htdocs/baikal1/baikal2/cal.php
REQUEST_URI: baikal1.example.com/baikal2/cal.php/…

• unexpected DOCUMENT_ROOT and subfolder

domain redirection: baikal1.example.com -> …/htdocs/baikal1/
DOCUMENT_ROOT: …/htdocs/
SCRIPT_FILENAME: …/htdocs/baikal1/baikal2/cal.php
REQUEST_URI: baikal1.example.com/baikal2/cal.php/…

@PascalTurbo: Due to the lack of details, I am not quite sure, if one of the cases fits to your problem.

I suggest the following update of Core/Frameworks/Flake/Framework.php to fix this problem:

# Determine PROJECT_BASEURI
# in some environments $_SERVER["DOCUMENT_ROOT"] . PROJECT_BASEURI != $_SERVER["SCRIPT_FILENAME"]
# PROJECT_BASEURI has to be calculated using $_SERVER["SCRIPT_FILENAME"] and $_SERVER["SCRIPT_NAME"]
# finde start of shared postfix of $_SERVER["SCRIPT_FILENAME"] and $_SERVER["SCRIPT_NAME"]
$i = 1;
while ($i <= min(strlen($_SERVER["SCRIPT_FILENAME"]),strlen($_SERVER["SCRIPT_NAME"]))
    && substr($_SERVER["SCRIPT_FILENAME"], -$i, 1) == substr($_SERVER["SCRIPT_NAME"], -$i, 1)) {
    $i++;
}
$sScript = substr($_SERVER["SCRIPT_FILENAME"], -($i-1), $i);    
unset($i);
$sScript = substr($sScript,strpos($sScript,DIRECTORY_SEPARATOR));   # remove path segement stubs
$sScript = substr($_SERVER["REQUEST_URI"],0,strrpos($_SERVER["REQUEST_URI"],preg_replace("/index\.php$/","",$sScript))) . $sScript; # get folder of the script (using preg_replace to remove automatically added index.php or similar)
$sDirName = str_replace("\\", "/", dirname($sScript));  # fix windows backslashes

It is clear, that this causes an calculation overhead, which would be an advantage of the parameter configuration.
$sScript is also used for calculation of PROJECT_URI. But I don't know if it solves @PascalTurbo s problem.

[evert]

Honestly i think it's important to try to not automatically detect anything if you have more complex needs.
imho it's better to find a way to hardcode your exact paths. None of these variables are universally reliable.

My understanding is that you're looking for a way to support the idea that the proxy base url is different than the origin url. To properly support this, it's not enough to just set the relevant $_SERVER variables. Every XML response for example would have incorrect urls.

[evert]

I'm closing this ticket because it's been a while since the last comment.

If this is indeed still an issue, feel free to comment here so we can continue discussing.

[Yenya]

Hello, I have a similar problem (upgrading to 0.7.0 from 0.4.x): I have

Alias /cal/ /somedir/baikal/html/

in my httpd.conf (/somedir/baikal/ being outside the DocumentRoot, I don't want to put the entire Baikal tree in my DocumentRoot). The main page (https://mydom.ain/cal/) as well as the admin page (https://mydom.ain/cal/admin/) works, but /cal/dav.php complains:

Requested uri (/cal/dav.php) is out of base uri (/al/html/dav.php/)

It seems the base uri guessing logic is wrong, but only for dav.php, and not for index.php nor admin/index.php.

[ByteHamster]

@Yenya have a look at #927. There you can find some workarounds. Also (if you have the time), I would be happy to hear what debug output you get when doing the steps outlined in #927.

[Yenya]

@ByteHamster: added comment to #928

I have also found (trying to run Baikal inside container with reverse-proxy in front of it), that Baikal even adds <base href=...> tag to its section instead of using relative or server-relative URLs, which complicates things for reverse proxies even further - having Apache listen at localhost:8888 means that Baikal - even the admin page - adds <base href="127.0.0.1:8888"> into its output, which obviously does not work outside the container it is running in.

Having the PROJECT_URI (as seen from the outside world) configurable instead of incorrectly trying to guess it would help. Also, the <base> tag should probably go away.