fix: use getenv() instead of $_SERVER in detectEnvironment()

[fcosrno]

Description
Update CodeIgniter.php to use getenv() instead of $_SERVER in detectEnvironment. The outcome of environment variables loading in either $_SERVER or $_ENV depends on the operating system and web server. For instance, in a Docker environment the .env file loads variables in $_ENV, resulting in detectEnvironment() not seeing CI_ENVIRONMENT when defined. Using getenv() instead of directly reading from $_SERVER solves this issue.

Fixes #6313

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[kenjis]

in a Docker environment the .env file loads variables in $_ENV, resulting in detectEnvironment() not seeing CI_ENVIRONMENT when defined. Using getenv() instead of directly reading from $_SERVER solves this issue.

Can't reproduce.

I checked phpinfo() output in my Docker environment.

• docker desktop 4.10.1
  • Engine: 20.10.17
  • Compose: v2.6.1

Environment
CI_ENVIRONMENT | development

PHP Variables
$_SERVER['CI_ENVIRONMENT'] | development
$_ENV['CI_ENVIRONMENT'] | development

[kenjis]

If you have .env file, setVariable() sets $_SERVER[$name] if it is empty().
I don't know why your $_SERVER['CI_ENVIRONMENT'] is not set.

CodeIgniter4/system/Config/DotEnv.php

Lines 89 to 102 in d75e426

	protected function setVariable(string $name, string $value = '')
	{
	if (! getenv($name, true)) {
	putenv("{$name}={$value}");
	}
	if (empty($_ENV[$name])) {
	$_ENV[$name] = $value;
	}
	if (empty($_SERVER[$name])) {
	$_SERVER[$name] = $value;
	}
	}

[fcosrno]

Yes @kenjis, that should be the case in the presence of a .env file, like when you COPY the file in the Dockerfile. But it's not the case when loading environment variables in other scenarios, like when using env_file in Docker Compose or in deployments without persistent date (no copying of .env files into containers). In my original comment I should have written "in a Docker environment the environment variables could load in $_ENV" and never in $_SERVER instead of explicitly calling out the .env file.

[kenjis]

Okay, I got your situation. You don't use .env file and set environment variable only.
And your PHP does not set $_SERVER['CI_ENVIRONMENT']. Maybe not FastCGI API.

By the way, why do we use $_SERVER['CI_ENVIRONMENT']?
It comes from environment variable, so why don't we use $_ENV['CI_ENVIRONMENT']?

[kenjis]

env() is slower than getenv().

$iterator->run(100000)

Test	Time	Memory
env()	0.3829	0 Bytes
getenv	0.3150	0 Bytes

[paulbalandan]

It may be slower because it checks all available places ($_SERVER, $_ENV, getenv()). But in cases where putenv is disabled for security reason, wouldn't getenv return false even if CI_ENVIRONMENT is really set?

[kenjis]

1. Disable putenv().

php.ini:

disable_functions = putenv

2. Remove .env file.

3. Make a controller.

class Home extends BaseController
{
    public function index()
    {
        return getenv('CI_ENVIRONMENT');
    }
}

4. Run local server with Environment Variable.

$ CI_ENVIRONMENT=development php spark serve

5. Navigate to http://localhost:8080/.

I see "development".

[kenjis]

It seems there are three options:

1. use $_ENV
2. use $_ENV or getenv() (If $_ENV is not set, call getenv())
3. use env()

[MGatner]

Oops, I reviewed before I saw this discussion. I'm fine with .07s performance hit if env() covers more possible scenarios, but if it adds nothing then going with the more barebones approach seems good. One other advantage of env() is that a developer could theoretically override it if they wanted to do some fancy loading of their own.

[kenjis]

variables_order in php.ini-production is GPCS.
So if not in CGI or FastCGI, $_ENV is not populated by default.
Using only $_ENV seems not good.

; This directive determines which super global arrays are registered when PHP
; starts up. G,P,C,E & S are abbreviations for the following respective super
; globals: GET, POST, COOKIE, ENV and SERVER. There is a performance penalty
; paid for the registration of these arrays and because ENV is not as commonly
; used as the others, ENV is not recommended on productions servers. You
; can still get access to the environment variables through getenv() should you
; need to.
; Default Value: "EGPCS"
; Development Value: "GPCS"
; Production Value: "GPCS";
; https://php.net/variables-order
variables_order = "GPCS"
https://github.com/php/php-src/blob/32d55f74229e7913db0d59ef874a401744479b6a/php.ini-production#L647

Warning
In both the CGI and FastCGI SAPIs, $_SERVER is also populated by values from the environment; S is always equivalent to ES regardless of the placement of E elsewhere in this directive.
https://www.php.net/manual/en/ini.core.php#ini.variables-order

[kenjis]

It seems Apache SetEnv sets $_SERVER, not $_ENV.

It is important to note that this new variable will appear in $_SERVER, not $_ENV.
https://www.php.net/manual/ja/reserved.variables.environment.php#97105

If so, the following setting does not set $_ENV.

SetEnv CI_ENVIRONMENT development
https://codeigniter4.github.io/CodeIgniter4/general/environments.html#environment-apache

Concluseion: using env() is safe.

[MGatner]

@fcosrno Are you available to confirm that env() fixes your issue? If so please update this PR.

If we don't hear back today I will merge #6257 (comment) and we can proceed with final review.

[fcosrno]

Yes, I can confirm env() fixes the issue.

[kenjis]

Okay, all green!
@fcosrno Thank you for confirmation.

[MGatner]

💪