2406cc7b43
This PR was squashed before being merged into the 2.3 branch (closes #16095).
Discussion
----------
[Console] Add additional ways to detect OS400 platform
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #16053
| License | MIT
| Doc PR | None
This PR adds support for detecting the OS400 platform when the PHP function `php_uname()` is disabled. OS400 platform detection was added in #15058 to fix character encoding issues present on OS400. See that PR for more info.
This PR fixes regression introduced in #16053, which did not work on the IBM OS400 server I have access to. The constant `PHP_OS` being checked outputs "AIX" on my IBM OS400 server. I can't say for sure if it works on other IBM platforms... but I preserved this check just in case.
User @eloigranado [commented here](https://github.com/symfony/symfony/pull/15058#issuecomment-130743928) asking if we could switch to using `PHP_OS` constant instead of `php_uname()` because he claims some admins might "[hide] the exact kernel build from any attacker who discovers a remote PHP code execution vulnerability". I personally don't think we should accommodate this use case, but I was able to find alternate approaches.
### Why use case insensitive string matching stristr() instead of in_array()?
Here are the various outputs on my OS400 server:
echo PHP_OS; // "AIX"
echo getenv('OSTYPE'); // "os400"
echo php_uname('s'); // "OS400"
So we have various case issues here, and possible blank values on platforms where OSTYPE var doesn't exist or php_uname() is disabled. Concatenating these optional values together delimited by ; then case-insensitive searching the string for "OS400" seemed like a fair compromise. I would've probably done `in_array()` if case wasn't an issue.
Commits
-------
|
||
|---|---|---|
| .. | ||
| Bridge | ||
| Bundle | ||
| Component | ||