Include Operation's resolved uriVariables items with `$resourceAccessCheckerContext` in `AccessCheckerProvider`

[rvanlaak]

Description

The security system is powerful, and allows defining complex expressions close to where the operation is defined. The $resourceAccessCheckerContext on \ApiPlatform\Symfony\Security\State\resourceAccessCheckerContext:76 only gets the previous_object, object, and request to work with and Symfony security added user already.

You'd expect the uriVariables to be available in there, and when possible for them to be resolved as items already. This allows leveraging the operation's capabilities to resolve items even further with regards to security.

Example

#[ApiResource(
    operations: [
        new Post(
            uriTemplate: '/me/foo/{foo}/bar',
            uriVariables: [
                'foo' => new Link(
                    toClass: Foo::class,
                ),
            ],
            security: "is_granted('ROLE_USER') and user.bar === foo.bar",
        ),
    )
]

The above right now will lead to a SyntaxError exception:

Variable "foo" is not valid around position 42 for expression `is_granted('ROLE_USER') and user.bar === foo.bar`.

[soyuka]

I think you've access to {foo} as a request attribute (as request is available) but you will get the uri variable as a string not an object, use the security link provider for that (there's some documentation IIRC)

[rvanlaak]

Guess you're referring to the ResourceAccessChecker? Of course it is possible to customize provider/controller on an operation, but that requires every situation to add lots of boilerplate code in having to implement a provider for a security check while the rest of the operation works perfectly. I now have operations that nicely work, but have the more complex security part commented out. And in addition, for a GetCollection operations the object to check on in security context is an array [].

From security perspective it would be extremely powerful if the ItemProvider would make the operation's uriVariables objects available to the ResourceAccessChecker. These variables are explicitly defined already, so there won't "leak" much more to the security check than one or two objects.

[soyuka]

I'm not, see:

core/src/State/ParameterProvider/ReadLinkParameterProvider.php

Line 90 in d640d10

$context['request']?->attributes->set($securityObjectName, $relation);

This provider can set a request attribute, and IIRC you have access to the request inside the security check. Also I think you've access to the current operation so you can easily do operation->getUriVariables()[0]->getValue() to make it work with say something like this:

core/src/State/ParameterProvider/IriConverterParameterProvider.php

Line 69 in d640d10

$parameter->setValue($entities);