Hi internals,
The filter_var functionality is one of the most efficient and well-known ways in PHP to validate and sanitize inputs for many use cases
(e.g. FILTER_VALIDATE_INT for checking if a string is well-formed decimal input (or other bases), FILTER_VALIDATE_BOOL for user input/configs (cli/server api), FILTER_VALIDATE_URL, FILTER_VALIDATE_EMAIL).
The filter_var functionality is something that you can disable with --disable-filter, and I've often encountered code with
a few dependencies or source files that assume that filter_var is always available when building php from source.
# Composer version 2.0.4 2020-10-30 22:39:11
sapi/cli/php ~/bin/composer.phar
Fatal error: Uncaught Error: Call to undefined function JsonSchema\Uri\filter_var() in phar:///path/to/bin/composer.phar/vendor/justinrainbow/json-schema/src/JsonSchema/Uri/UriResolver.php
# public function resolve($uri, $baseUri = null)
# {
# if (!is_null($baseUri) && !filter_var($baseUri, \FILTER_VALIDATE_URL) && ....
For me, the main reason why a developer/admin/hosting provider may want to disable the 'filter' module is
- The
filter_input()functionalities that allow direct access to the original POST/GET/COOKIE/ENV data.
e.g. this makes code harder to test if the code or third party libraries it
uses harder to unit test because $_GET/$_POST/$_COOKIE/$_ENV can't be replaced in filter_input. - The php build steps may have been carried over from PHP 5.2 when 'filter' was brand new and much less code used filter.
- Desire for slightly smaller installations
- Unaware of it since phpxyz-core and phpxyz-filter are different modules in an OS's package manager
The filters themselves(https://www.php.net/manual/en/filter.constants.php) seem to be free of side effects
glancing at the descriptions and implementation.
The fact that filter_var isn't enabled by default may lead to
- Application/library authors unconditionally using
intval()/floatval() or other functions in core that don't check for unexpected suffixes (e.g. '10MB')
Many languages have a function like atoi() that detects invalid integers - Applications skipping filtering steps if the function filter_var doesn't exist, e.g. allowing any string to be used as a url/email
- Dependencies failing to run due to throwing Errors on rare configurations where filter_var is unavailable.
It seems like filter is useful enough to already be statically compiled into the Windows builds published on windows.php.net
What are your thoughts on the following:
Move the following functions into core and statically build them:
(and all global FILTER_* constants but not INPUT_* from https://www.php.net/manual/en/filter.constants.php)
- filter_has_var — Checks if variable of specified type exists
- filter_id — Returns the filter ID belonging to a named filter
- filter_list — Returns a list of all supported filters
- filter_var_array — Gets multiple variables and optionally filters them
- filter_var — Filters a variable with a specified filter
Keep the following remaining functions in the 'filter' extension, continue enabling them by default and allowing --disable-filter to disable them:
- filter_input_array — Gets external variables and optionally filters them
- filter_input — Gets a specific external variable by name and optionally filters it
Thanks,
- Tyson