Deprecate access_control attribute, add security + security_post_denormalize attributes

[vincentchalamon]

Q	A
Waiting for PR?	#2990
Bug fix?	yes
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	#1646, api-platform/api-platform#1218
License	MIT
Doc PR	api-platform/docs#859

[dunglas]

Can you also add a legacy test for access_control?

[teohhanhui]

If we're really doing this, I'd suggest:

"access_control"={"precondition"="...","postcondition"="...",
},

[dunglas]

Sub-attributes are too verbose, I prefer this approach (see my comment in the related issue).

[soyuka]

Once tests pass 👍

We need to dig through older issues, I'm sure that this solves more then 2 issues :p.

[teohhanhui]

"security" and "late_security" are really confusing names.

If you don't want nested attributes, then perhaps:

• access_control_precondition
• access_control_postcondition

Or:

• authorize_precondition
• authorize_postcondition

The second option would fit nicely with my suggestion of renaming DenyAccessListener to AuthorizeListener. And of course we could support "authorize"=false.

I don't buy the argument that Symfony uses the term "security" too. It's not related to our case.

[dunglas]

Awesome! Thanks @vincentchalamon

[c-lambert]

Hello,
i'm not sure to understand the fix applied.
I use API Platform 2.6.4 with security annotation on itemOperation. But when i call this endpoint with unauthorized user, API Platform responds 404 when entity doesn't exist, and 403 when entity exist.

security attribute is not early by default ?

[norkunas]

security is executed only after reading data, so you could have dynamic security by object data, if you want to not expose that item exist you could use security acl for that

[c-lambert]

security is executed only after reading data, so you could have dynamic security by object data, if you want to not expose that item exist you could use security acl for that

Ok thank you, i'll do that.
I was hopping that we can bypass this behavior with a parameter.