LINEAGEOTA_BASE_PATH sourcing - use $_SERVER instead of $_ENV

[breakingspell]

Hello! Long story short, I had to make a quick modification to index.php so LINEAGEOTA_BASE_PATH could reach the API server, and i'm not sure if it's my apache configuration or something else:

When I first set the deployment up a few months ago, I needed to define env variable LINEAGEOTA_BASE_PATH for my reverse proxy, and updated to latest commit (latest tagged release that composer grabs is 2.9.0 without the change for $base_path).

I declared the variable in /etc/apache2/envvars as LINEAGEOTA_BASE_PATH=https://externalURL, however the server does not seem to see the variable, the API call would return "url":"http:\/\/internalURL:port\". Tried defining it in .htaccess as well, no dice.

I can confirm the variables in envvars were being set by viewing phpinfo() under Apache Environment:

SCRIPT_FILENAME | /var/www/LineageOTA/phpinfo.php
LINEAGEOTA_BASE_PATH | https://externalURL
HTTP_HOST | internalURL:port

index.php follows else here, but phpinfo() could resolve the variable.

if ( isset($_ENV['LINEAGEOTA_BASE_PATH']) )
        $base_path = $_ENV['LINEAGEOTA_BASE_PATH'];
    else
        $base_path = $protocol.$_SERVER['HTTP_HOST'].dirname($_SERVER['SCRIPT_NAME']);

After a bit of trial and error, I ended up modifying the file, changing:
$_ENV to $_SERVER

if ( isset($_SERVER['LINEAGEOTA_BASE_PATH']) )
        $base_path = $_SERVER['LINEAGEOTA_BASE_PATH'];

This allowed me to define the variable in /etc/apache2/sites-enabled/LineageOTA.conf with SetEnv LINEAGEOTA_BASE_PATH https://externalURL, where it is successfully read by the API server ("url":"https:\/\/externalURL\"), and downloads are able to commence on my phone with the corresponding prop.

I'd forgotten about this modification until I decided to redeploy the api server into my main Jenkins container, sure enough the same issue became visible again, and I made the same change to allow the variable to reach the server after troubleshooting Apache. Am I missing something in Apache2 regarding environment variables? Anyone had a similar experience/solution?

[julianxhokaxhiu]

Hi,

see #76 and relative commits/documentation.

$_ENV in PHP is used to be populated from the shell environment that is running the PHP process, so it's not a PHP env var, it's an environment env var. Make sure you're using using these ones and it should work OOB.

BR,
Julian

[breakingspell]

Thank you for the quick response and information, i've went ahead and reverted my edit to the latest revision, set the variable in envvars, and removed the line from site config. The variable should be set at the environment level when it's declared in /etc/apache2/envvars.

I looked further and noticed that the default PHP config at /etc/php/7.4/apache2/php.ini was indeed configured by default to exclude $_ENV per variables_order. The comments in php.ini note that getenv() is available for use while $_ENV was removed as a default due to performance penalties (non-issue here), that would explain why phpinfo() was able to resolve the variable.

variables_order = "GPCS"

Adding E to this string and restarting the instance allows the LineageOTA API to resolve LINEAGEOTA_BASE_PATH from envvars as intended out of the box.
The issue is resolved, but i'm still curious:

The default configuration for Apache/PHP on Debian seems to have been this way for some time, and it makes me wonder why the behavior hasn't been noticed yet, unless i'm going about it wrong. With this method, a future PHP upgrade would also require the extended variables_order value to include $_ENV.

Is there a drawback to using $_SERVER to populate LINEAGEOTA_BASE_PATH as I was doing with the workaround for a few months? This would involve less changes from defaults, as a user configuring a reverse proxy will likely be editing the apache site config for the endpoint already.

[julianxhokaxhiu]

It's set as an environment variable because this project is used also in a container first and foremost.

Regarding adapting it to use $_SERVER it would require that this project can be used only via an HTTP server, while in fact it can be run with a standalone PHP server. It's also true it's been a while I didn't use PHP intensively to pound risks but if you can come up with an easy flow that brings ENV vars to $_SERVER I'll be happy to adapt the code.

The important part is that it does not depend on single use cases, like Apache/Nginx only.