Deserializer before security

[vincentchalamon]

I have an ApiResource with an access control to ROLE_EMPLOYEE. When I send anonymously a request (with an iri of a non-existing object) to create an object, I get a 400, but I should receive a 403.

Entity:

/**
 * @ApiResource(attributes={
 * "access_control"="is_granted('ROLE_EMPLOYEE')"
 * })
 * …
 */
class Shipping
{
 /**
 * @var null|PsOrder
 * …
 */
 private $order;
}

Request:

{
 "order": "/ps_orders/1"
}

Response: Item not found for "/ps_orders/1".

Maybe it's just a question of priority with DenyAccessListener that should be higher than DeserializeListener.

@api-platform/core-team What status code would you expect in this case: 400 or 401/403?

[norkunas]

Current priority allows to deny based on deserialized data so imho this works as expected.

[vincentchalamon]

I've discussed that point with @dunglas, and yep this works as expected, as the access_control requires an object, so it needs to be deserialized first. But I still find it weird that I get a 400 instead of a 401/403

[Taluu]

IMO this is wrong to deny on a modified object on voters. Why ? Because before updating something, you should vote against the fetched object and not the modified object. An example : I have an object that has a relation to another one. I want to vote and accept * only * if this object is myself (so I'm the owner).

But if in my request I change that, well... I'm not voting against the correct object (it's modified), and thus I'm not allowed to do so. It should be the role of a validator.

On the case of POST, it may differ a bit, but no so much. Anyway, on collection operations, you don't vote against an object, so problem solved (you vote against the environment : user, context, ... and so on).

So IMO the security listener should be fired BEFORE the deserializer listener.

[weaverryan]

#2779 was merged, which allows you to use the original data in your access_control.

That's great! However, I still think the original problem from @vincentchalamon is valid:

 * @ApiResource(attributes={
 * "access_control"="is_granted('ROLE_EMPLOYEE')"
 * })

With this setup, my validation rules are executed and the client (who should not have access to this/these endpoints at all) gains the ability to see the validation rules for it.

[dunglas]

Indeed. We could do the security check after deserialization, but before validation. WDYT?

[antograssiot]

but that's already the case @dunglas

core/src/Bridge/Symfony/Bundle/Resources/config/security.xml

Line 24 in 125dec9

<tag name="kernel.event_listener" event="kernel.request" method="onKernelRequest" priority="1" />

core/src/Bridge/Symfony/Bundle/Resources/config/validator.xml

Line 23 in 2f941fc

<tag name="kernel.event_listener" event="kernel.view" method="onKernelView" priority="64" />

[dunglas]

So I don’t understand how this issue appears 😄. I’ll have to create a reproducer.

[soyuka]

Mhhh so this isn't fixed 😅 ?