> APIs > API Platform 3 Part 2: Security for your Treasures
Login to bookmark this video
Buy Access to Course
34.

Auto Setting the "owner"

|

Share this awesome video!

|

Keep on Learning!

Start your All-Access Pass

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Every DragonTreasure must have an owner... and to set that, when you POST to create a treasure, we require that field. I think we should make that optional. So, in the test, stop sending the owner field:

181 lines | tests/Functional/DragonTreasureResourceTest.php
// ... lines 1 - 12
class DragonTreasureResourceTest extends ApiTestCase
{
// ... lines 15 - 41
public function testPostToCreateTreasure(): void
{
// ... lines 44 - 45
$this->browser()
// ... lines 47 - 51
->post('/api/treasures', HttpOptions::json([
// ... lines 53 - 56
'owner' => '/api/users/'.$user->getId(),
]))
// ... lines 59 - 60
;
}
// ... lines 63 - 179
}

When this happens, let's automatically set it to the currently-authenticated user.

Make sure the test fails. Copy the method name... and run it:

symfony php bin/phpunit --filter=testPostToCreateTreasure

Nailed it. Got a 422, 201 expected. That 422 is a validation error from the owner property: this value should not be null.

Removing the Owner Validation

If we're going to make it optional, we need to remove that Assert\NotNull:

253 lines | src/Entity/DragonTreasure.php
// ... lines 1 - 88
class DragonTreasure
{
// ... lines 91 - 136
#[Assert\NotNull]
// ... line 138
private ?User $owner = null;
// ... lines 140 - 251
}

And now when we try the test:

symfony php bin/phpunit --filter=testPostToCreateTreasure

Well hello there gorgeous 500 error! Probably it's because the null owner_id is going kaboom when it hits the database. Yup!

Using the State Processors

So: how can we automatically set this field when it's not sent? In the previous API Platform 2 tutorial, I did this with an entity listener, which is a fine solution. But in API Platform 3, just like when we hashed the user password, there's now a really nice system for this: the state processor system.

As a reminder, our POST and PATCH endpoints for DragonTreasure already have a state processor that comes from Doctrine: it's responsible for saving the object to the database. Our goal will feel familiar at this point: to decorate that state process so we can run extra code before saving.

Like before, start by running:

php bin/console make:state-processor

Call it DragonTreasureSetOwnerProcessor:

15 lines | src/State/DragonTreasureSetOwnerProcessor.php
// ... lines 1 - 2
namespace App\State;
use ApiPlatform\Metadata\Operation;
use ApiPlatform\State\ProcessorInterface;
class DragonTreasureSetOwnerProcessor implements ProcessorInterface
{
public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []): void
{
// Handle the state
}
}

Over in src/State/, open that up. Ok, let's decorate! Add the construct method with private ProcessorInterface $innerProcessor:

21 lines | src/State/DragonTreasureSetOwnerProcessor.php
// ... lines 1 - 5
use ApiPlatform\State\ProcessorInterface;
// ... lines 7 - 9
class DragonTreasureSetOwnerProcessor implements ProcessorInterface
{
public function __construct(private ProcessorInterface $innerProcessor)
{
}
// ... lines 15 - 19
}

Tip

In API Platform 3.2 and higher, you should return $this->innerProcessor->process(). This is also a safe thing to do in 3.0 & 3.1.

Then down in process(), call that! This method doesn't return anything - it has a void return - so we just need $this->innerProcessor - don't forget that part like I am - ->process() passing $data, $operation, $uriVariables and $context:

21 lines | src/State/DragonTreasureSetOwnerProcessor.php
// ... lines 1 - 9
class DragonTreasureSetOwnerProcessor implements ProcessorInterface
{
// ... lines 12 - 15
public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []): void
{
$this->innerProcessor->process($data, $operation, $uriVariables, $context);
}
}

Now, to make Symfony use our state processor instead of the normal one from Doctrine, add #[AsDecorator]... and the id of the service is api_platform.doctrine.orm.state.persist_processor:

21 lines | src/State/DragonTreasureSetOwnerProcessor.php
// ... lines 1 - 6
use Symfony\Component\DependencyInjection\Attribute\AsDecorator;
#[AsDecorator('api_platform.doctrine.orm.state.persist_processor')]
class DragonTreasureSetOwnerProcessor implements ProcessorInterface
{
// ... lines 12 - 19
}

Cool! Now, everything that uses that service in the system will be passed our service instead... and then the original will be passed into us.

Decorating Multiple Times is Ok!

Oh, and there's something cool going on. Look at UserHashPasswordStateProcessor. We're decorating the same thing there! Yea, we're decorating that service twice, which is totally allowed! Internally, this will create a, sort of, chain of decorated services.

Ok, let's get to work setting the owner. Autowire our favorite Security service so we can figure out who is logged in:

27 lines | src/State/DragonTreasureSetOwnerProcessor.php
// ... lines 1 - 7
use Symfony\Bundle\SecurityBundle\Security;
// ... lines 9 - 11
class DragonTreasureSetOwnerProcessor implements ProcessorInterface
{
public function __construct(private ProcessorInterface $innerProcessor, private Security $security)
{
}
// ... lines 17 - 25
}

Then, before we do the saving, if $data is an instanceof DragonTreasure and $data->getOwner() is null and $this->security->getUser() - making sure the user is logged in - then $data->setOwner($this->security->getUser()):

27 lines | src/State/DragonTreasureSetOwnerProcessor.php
// ... lines 1 - 11
class DragonTreasureSetOwnerProcessor implements ProcessorInterface
{
// ... lines 14 - 17
public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []): void
{
if ($data instanceof DragonTreasure && $data->getOwner() === null && $this->security->getUser()) {
$data->setOwner($this->security->getUser());
}
$this->innerProcessor->process($data, $operation, $uriVariables, $context);
}
}

That should do it! Run that test:

symfony php bin/phpunit --filter=testPostToCreateTreasure

Yikes! Allowed memory size exhausted. I smell recursion! Because... I'm calling process() on myself: I need $this->innerProcessor->process():

27 lines | src/State/DragonTreasureSetOwnerProcessor.php
// ... lines 1 - 11
class DragonTreasureSetOwnerProcessor implements ProcessorInterface
{
// ... lines 14 - 17
public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []): void
{
// ... lines 20 - 23
$this->innerProcessor->process($data, $operation, $uriVariables, $context);
}
}

Now:

symfony php bin/phpunit --filter=testPostToCreateTreasure

A passing test is so much cooler than recursion. And the owner field is now optional!

Next: we currently return all treasures from our GET collection endpoint, including unpublished treasures. Let's fix that by modifying the query behind that endpoint to hide them.