You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using ORM pagination and calling something like http://localhost/galery/page/2?direction[test]=1&sort=columnname, the direction parameter becomes an array. This will result in an array to string conversion error in the 3.6.0 QuerySubscriber. The 4.1.0 QuerySubscriber looks like it could be affected, too.
First, I thought about a quick is_string() check. But then I noticed that other places like the SlidingPagination in the KnpPaginatorBundle rely on the direction parameter to be a string, too. It seems that more than one class gets the value directly from the request. So my current idea is fixing the request with a kernel event subscriber like this draft:
final class SanitizeKnpPaginationParameters implements EventSubscriberInterface
{
public static function getSubscribedEvents(): array
{
return [
KernelEvents::REQUEST => ['onKernelRequest', 10],
];
}
public function onKernelRequest(RequestEvent $event): void
{
$direction = $event->getRequest()->query->get('direction');
if (null === $direction || \is_string($direction)) {
return;
}
$event->getRequest()->query->set('direction', 'desc');
}
}
What do you think? I'm not convinced this steamroller approach is an elegant solution.
I'd be happy to open a PR when we have a good notion on how to do it. (If so, could I target a 3.x branch or are PRs only accepted on the current major?)
The text was updated successfully, but these errors were encountered:
IMHO, using an EventSubscriber approach like the one above is a bit like "I don't know who and where you're going to use it, so I'll fix this upfront in a central place".
That's surprising for developers working on this library, since you wonder (no obvious hints) where the type conversion happens.
Also, from looking at the code in the event subscribers, you might also ask whether or not this type-checking takes place at all. Includes static analysis tools that may not see the actual types.
What about using \Symfony\Component\HttpFoundation\ParameterBag::filter() to access these parameters, passing FILTER_REQUIRE_SCALAR for $options?
Unfortunately the RFC in #306 didn't gain momentum, but anyway the implementation already started, and in the 4.x branch you can access arguments using your own implementation.
Affected version: 3.6.0 (possibly 4.1.0 as well)
When using ORM pagination and calling something like
http://localhost/galery/page/2?direction[test]=1&sort=columnname
, thedirection
parameter becomes an array. This will result in an array to string conversion error in the 3.6.0 QuerySubscriber. The 4.1.0 QuerySubscriber looks like it could be affected, too.First, I thought about a quick
is_string()
check. But then I noticed that other places like the SlidingPagination in the KnpPaginatorBundle rely on thedirection
parameter to be a string, too. It seems that more than one class gets the value directly from the request. So my current idea is fixing the request with a kernel event subscriber like this draft:What do you think? I'm not convinced this steamroller approach is an elegant solution.
I'd be happy to open a PR when we have a good notion on how to do it. (If so, could I target a 3.x branch or are PRs only accepted on the current major?)
The text was updated successfully, but these errors were encountered: