Votante de seguridad

Hey @Dejan94!

You're absolutely correct! And that's a really great point to bring up. Suppose you add a security attribute like this to your GetCollection:

new GetCollection(
    security: 'is_granted("EDIT", object)',
),

In this situation, the object is actually a "collection" - it's an array or maybe a Doctrine Collection object, I can't actually remember. The point is: it's not a single object. And that makes sene: if your endpoint returns 10 treasures, you might have access to EDIT 5 of them, but not the other 5.

So, unfortunately, for the GetCollection operation, if you want to use security to "filter" the collection automatically so that only some are shown, that's not done directly via security. Instead, in chapter 35 (will be released this week - but you can peek at it here https://symfonycasts.com/screencast/api-platform-security/query-extension or download the course code and look at the final directory to see what we did), we create a "query extension" that uses our security logic to modify the query itself to only returns the ones we have access to.

Let me know if that helps... or if it didn't ;).

Cheers!

Hmm, I think I've found more to this problem (I'm having the same problem). The first problem (as you mentioned ryan) is: access may be denied for some of the DragonTreasures in the collection. (This is solved by "CH35: Query Extension: Auto-Filter a Collection".)

The second problem (which doesn't seem to have symfonycasts documentation) is that the $subject passed in to the voter isSupports fails because it's a Paginator object of DragonTreasure objects (and not a normal DragonTreasure object).

Have I missed the video on this? I can't seem too find any on Symfonycasts

Would the best way to handle a Paginator object (within the voter) be to pop off a DragonTreasure from the paginators iterable and inspect that (and then assume the rest of the objects in the pagniator are of the same type)?

FYI: there's a response on Stackoverflow that has a different approach for using voters on GET collection endpoints (but loses the ability to inspect the object):

https://stackoverflow.com/questions/59051663/using-symfony-voters-on-collectionoperations-get

Hi Dejan and Ryan

I don't know if is the best option, but for collections, I use a provider to handle it, if the operation is an instance of CollectionOperationInterface I verify in a custom logic if the user is allowed.

Cheers!

I think that's a fine approach. In general, I haven't had this problem. What I mean is, for the GetCollection operation, I either allow access to that endpoint or I don't. Then, based on the user, a query collection extension, I filter it so that they only see the results they want. This means that there is never a time when I need to look at the individual results in the paginator to see if the user should have access: I've already controlled the results in there via the query extension.

It is unfortunate that you need a voter to deny access to a single item & a query extension to control the query to limit results in a collection (i.e. it's unfortunate that you sort of have the security logic in 2 places), but this is the way i handle this :).

Cheers!

Hey Cameron,

I'm happy to hear you were able to solve it yourself, well done!

Cheers!