Subrecursos

Hey Ryan, I have some question regarding subresource (maybe that's not even the solution to my problem):

So we're building a Web-App where a user can manage one or more projects, and the has DIFFERENT roles/permissions for every project. In one he is the manager and sees almost everything, in the other, he is just a normal user and sees only his own stuff. How should I handle the request/uris and permission?

1) With Subresources like /project/123/task/456, so it's perfectly clear how to access the data, but every ApiResouce needs to be prefixed with "project/:projectId". How do I know the User has the sufficient privileges to access the project or the task? I can't use Default Role Voter, cause it uses the User->roles property that is unaware of the current project (like "is_granted")
2) With Filters as payload (but won't work for GET requests, or?)
3) Maybe some kind of state, like a POST selectProject {id: 123} that sets some kind of session value that is automatically injected in every query (in a QueryExtension)

All in all I think it should be possible with the above ideas, but it feels like a lot of effort

Hey @Sebastian-K!

Hmm, interesting! Subresources are cool - and are MUCH nicer than in API Platform 2 (they were kind of a hacked addon the, but they're a first-class citizen now). And so, we can definitely use them. But we also may not need to.

Look at the URL: /project/123/task/456. That's gorgeous! But /task/456 is technically just as functional. If each Task has a relation to its Project, then from /task/456, we can look up the project from the Task and then see if the currently-authenticated user is an owner or not. Actually, even if I used subresources, I'd do the same thing: subresources are ultimately a bit of a "vanity" URL. At the end of the day, the object being loaded is Task with id 456.

So, for security, I'd create a custom voter (you're right that the default Role voter doesn't work when you need to decide permission based on some data - like I DO have permission to see Task 456, but not Task 123). Fortunately, we show this a bit in the next episode - https://symfonycasts.com/screencast/api-platform-security/access-control-voter - we first (in earlier chapters) show security using an expression, then we refactor it to a voter here. This strategy I think would work the same whether you decided to use a subresource or not. The /project/123 part of the URL just isn't that important (again, when you go to /project/123/task/456, it really just queries for Task 456 and THEN you run security checks. I DO think, though you could verify, that if a mischievous user changed the URL to /project/111/task/456, where Task DOES belong to Project 123, then it would result in a 404).

For "collection" resources, the strategy for filtering is slightly different - we talk about it here - https://symfonycasts.com/screencast/api-platform-security/query-extension

This part MAY differ slightly based on if you're using a subresource or not - but I'm not entirely sure:

A) If you do /tasks, then you can use a query extension like above to modify the query to only return tasks that are related to projects that the current user should have access to.

B) If you do /project/123/tasks, then API Platform will automatically only show tasks for project 123. But, what if the user doesn't have access to Project 123 at all? I'm actually not entirely sure how to handle this. The simplest solution is to, like with (A), create a query extension "to only return tasks that are related to projects that the current user should have access to". In that case, if the user doesn't have access to Project 123, the query would effectively be:

Find tasks WHERE project = 123 (this part is added by API Platform thanks to the subresource) AND (your custom part to filter to only projects the current user has access to).

So you'd filter to only tasks for projects the user should be able to see... and if that doesn't include project 123, it would result in null rows. The other way to do it would be to make /projects/123/tasks return a 404, but I'm not entirely sure how to do that :).

Let me know if this helps!

Cheers!

Thanks for the reply. Gave me new points to think about

I would now have defined /users/{user_id}/treasures.{_format} in User and /treasures/{treasure_id}/owner.{_format} in DragonTreasure.
Is there a reason why this is so twisted, purely from the grouping of the namespaces I find it so very strange.

Hey @urk!

Is there a reason why this is so twisted, purely from the grouping of the namespaces I find it so very strange.

I assume you're referring to how the sub-resources almost seem "backward" in the class they live in, right? Like the /users/{user_id}/treasures.{_format} is a "subresource under user"... and yet we put it into DragonTreasure.

I agree that it's a bit weird... but I think it would be weird the other way too. No perfect option :). The logic is that, because /users/{user_id}/treasures.{_format} will return "dragon treasures",. that's the class it should live on. It's almost like this is just a "vanity URL" / a different way to fetch dragon treasures. Of course, the downside is that the operations that we think of as "operations under /api/users" are split between multiple classes.

Anyway, I hope that gives some explanation at least!

Cheers!

Hey Ryan

Yes, you heard me correctly and I know what you mean.
It depends from which side you look at it. But it doesn't really have a technical reason. Thank you.

Thanks and cheers, Urs

How can I generate the route from the $iriConverter class? That is, I don't want to hardcode the route (for the same reason I use path() in twig and never hard-code the route)

#[ApiResource(
    uriTemplate: '/users/{user_id}/treasures.{_format}',
    shortName: 'Treasure',
    operations: [new GetCollection()],
    uriVariables: [
        'user_id' => new Link(
            fromProperty: 'dragonTreasures',
            fromClass: User::class,
        ),
    ],
)]

Version 2 of API Platform had a concept of subresources, version 3 doesn't, but I'm not sure what to pass to create the route.

$userId = 4;
$url = $iriConverter->getSubresourceIriFromResourceClass(
    $user::class,
    [
        'subresource_identifiers' => ['id' => $userId],
        'subresource_resources' => [Treasure::class => null],
    ]
); 

assert($url == '/users/4/treasures')

Hey @Tac-Tacelosky!

Hmm, that's a good question! I've not done this yet, but... the getIriFromResource() method has a 3rd argument Operation $operation = null. But it looks a little tricky.

First, I think you need to give your operation a name - apparently you can add name: 'foo' inside an operation - like a new GetCollection(name: 'my_subresource_get_collection'). Then, to fetch that object, I think you can do this:

public function someAction(ResourceMetadataCollectionFactoryInterface $resourceMetadata, IriConverterInterface $iriConverter)
{
    $operation = $resourceMetadata->getOperation('my_subresource_get_collection');
    $url = iriConverter->getIriFromResource($yourObject, UrlGeneratorInterface::ABS_PATH, $operation);

Give that a try - I might not have things quite right - a bit of digging and guessing to find this - a new part of the code for me!

Cheers!

Hey!
Thanks a lot for this tutorial, but I found nothing about security in here. I mean especially the way to protect only read relations of a user for the user itself. Will there be another tutorial for handling voters etc.?
Thank you for your answer!

Hey Thomas,

yes, you're right, in this tutorial we don't talk about security, that's the topic of our next tutorial https://symfonycasts.com/screencast/api-platform3-security
it's going to be released soon :)

Cheers!

Wow - that's what I hoped!
Thank you for replying!