New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More query parameter validation (follow #1692) #1723
More query parameter validation (follow #1692) #1723
Conversation
ffda2b9
to
ff95aeb
Compare
ff95aeb
to
d612479
Compare
I'm kind of stuck with the error here : I rebased on master, but 4cc6152 now throw an error Can somebody knowing GraphQL help me ? |
8c9677c
to
44a8c2e
Compare
OK I found the issue, it come from the filters containing
If I set "string" or "int", the test does work (but the new tests does not work of course). What is the real definition behind the I can "hack" and allow "int" and "float" inside this PR but I don't know if it's a good way to make this regarding api-platform point of view. Thanks |
948f314
to
cbf3f68
Compare
d8d205a
to
745c431
Compare
I've put myself a reminder to review this, let's focus on #1692 first. |
@jdeniau could you rebase this? Thanks! |
745c431
to
abbd47d
Compare
ce49bb9
to
9b07b3a
Compare
@dunglas @meyerbaptiste @soyuka Everything should be good for me, except the problem with "number" type that I mentionned earlier. |
9b07b3a
to
c7fffe6
Compare
c7fffe6
to
1622e45
Compare
I finally got time to rework on that, and made the same choice as defined in core/src/Swagger/Serializer/DocumentationNormalizer.php Lines 658 to 660 in 5b5e6b7
float , it will be converted to number for openapi.
This way, it's more "PHP-friendly". |
c99d8eb
to
3ec427e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one, we should merge this as a new feature! WDYT @api-platform/core-team
Let's merge to avoid further conflicts, we can always come back to some parts of the code if there's smth to change. Thanks a lot @jdeniau for the work! |
@soyuka Thanks a lot 🙏 If there is anything to change, I will try to be as quick as possible ! |
Does this allows to configure a |
Looking at example I'd need to create a custom filter class which would apply the "required" as true, yes? Instead I'd expect something like:
|
I guess we need docs now :D |
Totally! I will work on it!
Le ven. 20 déc. 2019 à 10:55, Antoine Bluchet <notifications@github.com> a
écrit :
… I guess we need docs now :D
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1723?email_source=notifications&email_token=AAKVNRPXQQBZUGUQ3QVBC4TQZSJB7A5CNFSM4ER3MVMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHMPCCY#issuecomment-567865611>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKVNRPPBOX2MEMEPQNS7GTQZSJB7ANCNFSM4ER3MVMA>
.
|
How to use it? Is there an example? my temporaty bad solution:
and SearchRequiredFilter class:
I understand this is a very bad solution, but how to do my task correctly? P.S. |
First point : I will work on documentation soon. It is on my to-do list.
Second point : your solution seems good to me, as it is a complicated case,
you will need to have a complex appproach for that. The only point may be
to not extend SearchFilter but create a real custom filter.
Le mar. 28 janv. 2020 à 15:50, winzza <notifications@github.com> a écrit :
… How to use it? Is there an example?
I need SearchFilter::class with required=true. I would also like to
dynamically set required = true (dependent on user role). How can i do
this?
my temporaty bad solution:
/**
* @ApiResource(
* // ... rules
* )
* @ApiFilter(SearchRequiredFilter::class, properties={"foo": "exact", "bar": "exact"})
* @Orm\Entity(repositoryClass="App\Repository\ProjectChatRepository")
*/
class User
{ ... }
and SearchRequiredFilter class:
//src/Filter
<?php
declare(strict_types=1);
namespace App\Filter;
// ... many use ...
class SearchRequiredFilter extends SearchFilter
{
/**
* @var Security
*/
private $security;
public function __construct(
Security $security,
// ... parent params
) {
parent::__construct(
// parents property
);
$this->security = $security;
}
public function getDescription(string $resourceClass): array
{
$description = parent::getDescription($resourceClass);
foreach ($description as &$options) {
if (!$options['is_collection']
&& $this->security->isGranted('ROLE_USER')
) {
$options['required'] = true;
}
}
return $description;
}
}
I understand this is a very bad solution, but how to do my task correctly?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1723?email_source=notifications&email_token=AAKVNRIE46NN4BELFJAGD43RABA3BA5CNFSM4ER3MVMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKDSGFA#issuecomment-579281684>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKVNRNKJQQSYJ3ZFGSCZPTRABA3BANCNFSM4ER3MVMA>
.
|
Would it be possible to run a custom validation callback on a filter that is not applied to any entity property? |
@efpapado for the moment, there are only "swagger" filter validators. (See https://github.com/api-platform/core/blob/master/src/Filter/QueryParameterValidator.php#L35-L43 for more informations) If you want to run a custom callback in a custom filter file, I think you can easily do something like that: class FooFilter implements FilterInterface
{
public function apply(QueryBuilder $queryBuilder, QueryNameGeneratorInterface $queryNameGenerator, string $resourceClass, string $operationName = null)
{
$this->throwIfSomethingIsWrong();
// normal filter behaviour
}
} |
Thank you so much!!! I wasn't aware of the |
@efpapado You're welcome ! For the record, it is not available in the base ApiPlatform\Core\Api\FilterInterface, but it is available in the doctrine bridge ApiPlatform\Core\Bridge\Doctrine\Orm\Filter\FilterInterface. It is mentionned in the documentation about custom filter, but in the documentation, the easier Theoretically, you can hook into both |
This follows #1692
It implements all other validation filters from OpenApi specification
This might break wrongly configured api though. I see two possible solutions here:
[Might break]
as we can consider wrongly configured sites a "bug"validate_filters
, default tofalse
, and deprecate it being tofalse
, encouraging people to set it totrue
, and remove the configuration key in 3.0