Harden range filter labels against malformed values - #1255
Open
Betafer wants to merge 1 commit into
Open
Conversation
|
Hello @Betafer! This is your first pull request on ps_facetedsearch repository of the PrestaShop project. Thank you, and welcome to this Open Source community! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
This PR makes range filter label generation resilient to malformed range values coming from the faceted search URL.
SearchProvider::labelRangeFilters()currently passes active range values directly toformatNumber()/formatPrice(). If a crafted URL provides a non-numeric range boundary, for example an HTML-like string, PrestaShop can throw a localization/decimal parsing exception while rendering category facets.The change adds a small numeric boundary guard: valid numeric scalar values are preserved, invalid values fall back to the facet min/max, and a final
0fallback is used only if both values are invalid.Why
This prevents category/listing pages from failing when bots or malicious requests submit malformed price/weight range boundaries.
Tests
php -l src/Product/SearchProvider.phpphp -l tests/php/FacetedSearch/Product/SearchProviderTest.phpPHP_CS_FIXER_IGNORE_ENV=1 vendor/bin/php-cs-fixer fix --no-interaction --dry-run --diff --config=.php_cs.dist src/Product/SearchProvider.php tests/php/FacetedSearch/Product/SearchProviderTest.phpq=Prezzo-<a><a><a><a><a>-100AJAX category requests now return HTTP 200 and valid rendered products/facets instead of throwingcannot be interpreted as a number.Note: the full legacy PHPUnit 5 suite could not run in my local environment because it is incompatible with PHP 8.1 (
Cannot acquire reference to $GLOBALS).