Chapters

39 Chapters | 4:45:13 |

01

Hello API Security + API Docs on Production?

8:55
02

API Auth 101: Session? Cookies? Tokens?

4:05
03

Login with json_login

6:27
04

Authentication Errors

5:55
05

Login Success & the Session

4:28
06

On Authentication Success

7:40
07

Logout & Passing API Data to JS on Page Load

8:49
08

SameSite Cookies & CSRF Attacks

8:06
09

ApiResource access_control

6:03
10

Bootstrapping a Test Suite

4:29
11

Backport the API Platform 2.5 Test Tools

5:01
12

Api Tests & Assertions

6:51
13

Logging in Inside the Test

6:57
14

Resetting the Database Between Tests

4:51
15

Base Test Class full of Goodies

8:30
16

ACL: Only Owners can PUT a CheeseListing

9:23
17

ACL & previousObject

8:04
18

Access Control & Voters

8:25
19

Adding the plainPassword Field

7:31
20

Data Persister: Encoding the Plain Password

8:03
21

Validation Groups

5:44
22

Conditional Field Setup

6:42
23

Testing, Updating Roles & Refreshing Data

9:22
24

Context Builder & Service Decoration

6:50
25

Context Builder: Dynamic Fields/Groups

7:47
26

Automatic Serialization Groups

5:59
27

Resource Metadata Factory: Dynamic ApiResource Options

8:45
28

Dynamic Groups without Caching

10:34
29

Custom Normalizer: Object-by-Object Dynamic Fields

9:30
30

Diving into the Normalizer Internals

4:49
31

A "Normalizer Aware" Normalizer

6:49
32

Normalizer & Completely Custom Fields

7:32
33

Locking down the CheeseListing.owner Field

8:16
34

Custom Validator

5:40
35

Security Logic in the Validator

6:46
36

Auto-set the Owner: Entity Listener

9:46
37

Query Extension: Auto-Filter a Collection

9:37
38

Automatic 404 on Unpublished Items

5:26
39

Filtering Related Collections

10:50

This tutorial has a new version, check it out!

> Symfony 5 > API Platform 2 Part 2: Security

Buy Access to Course

35.

Security Logic in the Validator

|

Autoplay

Keep on Learning!

If you liked what you've learned so far, dive in! Subscribe to get
access to this tutorial plus video, code and script downloads.

Start your All-Access Pass

Buy just this tutorial for $12.00

Previous Chapter

Next Chapter

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

Login Subscribe

Login or register to check out the script

17 Comments

Sort By

Login or Register to join the conversation

Stephane 4 years ago edited

If you want to use attributes with PHP 8, you have to modify class IsValidOwner like that :


#[\Attribute]
class IsValidOwner extends Constraint {}

Into CheeseListing class :


use App\Validator as AppAssert;
class CheeseListing
{
    #[AppAssert\IsValidOwner]
    private User $owner;
}

I noted with ApiPlatform 2.6, we have to use $this->assertResponseStatusCodeSame(422, 'not passing the correct owner'); instead of $this->assertResponseStatusCodeSame(400, 'not passing the correct owner');

|

Victor SFCASTS Stephane 4 years ago

Hey Stephane,

Thank you for sharing the code that uses PHP 8 attributes! And thanks for the tip about return status code, I think we will add a note about it

Cheers!

|

Simon L. 5 years ago

Hi there!

Tell me if I am wrong but even if the validator triggers a violation (and thus a 400 error), the request will still be written into the database.

For example, if a user (not admin) wants to set another user of his choice as author to an existing post, his put request will return a 400 error, with the customized error message, but in the database, the owner will effectively be changed...

In your test, please do not use only $this->assertResponseStatusCodeSame(400), but compare also the previous data to the data in the database after the request has been made.

For example, an assertion like this one:
$user = $em->getRepository(UserObject::class)->findOneBy(['username' => 'XXXX']);
$this->assertEquals($prevUuid, $user->getId());

For my part, I had to add this kind of code into the validator to be sure that the query hasn't changed my data in the database even after a validator violation:
$previousStatus = $this->em->getUnitOfWork()->getOriginalEntityData($value)['status'];
$value->setStatus($previousStatus)

So maybe I did something wrong somewhere, so let me know please :)

|

weaverryan SFCASTS Simon L. 5 years ago edited

Hey Simon L. !

Hmm. So, this definitely should not be happening. It totally may be happening... but it should - so we need to figure out what's going wrong! :)

First, the problem could just be in the test. I don't know what your full test looks like, but it's possible that your test is using "out of date" data. That's because this is what happens behind the scenes:

A) In the test, when you create the Client object, that boots Symfony's kernel & container
B) When you make a request in the test, that request is made through that kernel. This means that if you have, for example, a CheeseListing object in your test (maybe you created one and are actually testing to see if you can update to a different owner), that is literally the same object that will be "modified" in your request.
C) And so, even though the modified CheeseListing was never saved to the database, the CheeseListing in your test was modified and so your assertion makes it appear that it was modified (but really, the data is coming from "memory" and not from the database).

This may or may not be the issue, but I wanted to mention it first. It's an annoying little thing in tests. To be sure, "refresh" any objects before you run an assertion on them - e.g. $em->refresh($cheeseListing). Even re-querying (e.g. $em->getRepository(UserObject::class)->findOneBy(['username' => 'XXXX']);) may not be enough because Doctrine is smart and tries to re-use things in memory whenever possible to avoid a fresh query.

Anyways, if this is NOT it, then you're right: something is saving this. But, as I mentioned, it "shouldn't" happen. It is however possible: if anything else in your system called $em->flush() after the object was modified (I can't think of why something might do this, but it's possible you have some custom listener or something somewhere) then it would cause any modified objects to be flushed. This is a known "quirk" of how Symfony's validator system works: the fact that you need to modify an object before you validate it means that if something accidentally calls flush later during the same request, then it will flush that object. In practice, I've never been bit by this - it would likely only be possible if you had an event listener on Symfony's ResponseEvent or ExceptionEvent that flushed something to the database.

Anyways, let me know what you find out!

Cheers!

|

Simon L. weaverryan 5 years ago edited

Hi weaverryan !

I don't know what to say... You are such an expert... You were totally right about the test behaviour. If I refresh the object, it works well...

Again, thank you so much for your in-depth help and your great quality courses.

Have a great day :)

|

weaverryan SFCASTS Simon L. 5 years ago edited

Hey Simon L.!

Sweet! Glad we got it worked out! That test behavior is *tricky*, unfortunately!

Cheers!

|

Simon L. 5 years ago edited

Hi there !

Validators are great. But just to check if I understood everything well, could we achieve the same result using Voters and "security_post_denormalize" as described below:

In the Entity:
`
/**

@ApiResource(
collectionOperations={
"post" = {
"security_post_denormalize" = "is_granted('CHEESE_CREATE', object)",
},
},
`

(In my example, I do not want all users to be able to create a cheese_listing, only the one with CHEESE_CREATE role, but it could be that every user can have this role, it doesn't really change the logic I want to point out).

In the voter:
Some logic to check if (object->getOwner() === $user) OR ($user is admin)

By using Voters we can sort users with a specific role (eg. CHEESE_CREATE), but we could do that in Validators too (by checking $user->getRoles()).

Am I wrong ?

|

MolloKhan SFCASTS Simon L. 5 years ago edited

Hey Simon L.

Validating data and authorizing access are two different things. Validators are meant to, well, validate that your data is in a healthy/expected state, and authorizing is for doing things like you want

It's not recommended to grant access to some resource by checking a user's roles via the getRoles() method, you have to do it via the is_granted() function

I hope it makes sense to you. Cheers!

1 |

Simon L. MolloKhan 5 years ago edited

Hi MolloKhan !

Thanks for your reply :)

|

julien_bonnier 6 years ago

Hi there,

Just wondering, why isn't the throw statement on top of the validator's validate method?

|

sadikoff julien_bonnier 6 years ago edited

Hey julien_bonnier

Did you mean docblock above function definition?

Cheers!

|

Hannah R. 6 years ago

Lets say i have a User with ROLE_EDITOR who is not the owner.
If this user is trying to edit the cheeselisting, without trying to set the owner field, there will be a violation.

Shouldnt there only be a validation check for $value->getId() !== $user->getId()) if the owner field is being set or updated?

|

MolloKhan SFCASTS Hannah R. 6 years ago edited

Hey Hannah R.

I think you will need to create a custom Voter for implementing such logic. In this chapter you can watch (or read) how to do it https://symfonycasts.com/sc...

Cheers!

|

Hannah R. MolloKhan 6 years ago edited

Hey MolloKhan ,
just to make it clear: i have a voter that allows users with ROLE_EDITOR to edit a cheeseListing (as in the chapter you linked). But if any user with ROLE_EDITOR is trying to edit the cheeseListing, this Validator is preventing it. Because it checks for $value->getId() !== $user->getId()) even if the owner field is not being updated.

If ROLE_EDITOR tries to update the title only for example, it fails with "Cannot set owner to a different user". The user with ROLE_EDITOR didn't try to set the owner ... Its not even writebale with a put or patch because the owner field has this in the annotation:

@Groups({"cheeselisting:read", "cheeselisting:collection:post"})

|

MolloKhan SFCASTS Hannah R. 6 years ago edited

Hey Hannah R.

Got it now. The problem comes from the IsValidOwnerValidator, you need make it smarter. If the logged in User has the role ROLE_EDITOR, then, you'll have to check that the owner property didn't change. To do that, you'll need to get the initial version of your CheeseListing object. It's a bit tricky because of how Doctrine + Symfony Forms works but here I leave you a good article I found that explains how to do so https://medium.com/@ger86/symfony-validate-an-object-based-on-its-previous-version-4b6ca7a85dc6 - scroll down to the Defining a “Validator” class section

Cheers!

|

Alberto rafael P. 6 years ago

Tengo muchas ganas de ver este tambien

|

Ad F. Alberto rafael P. 6 years ago

English Only :)

1 |

This tutorial works great for Symfony 5 and API Platform 2.5/2.6.

Symfony 4 API Platform 2.4

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": "^7.1.3, <8.0",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "api-platform/core": "^2.1", // v2.4.5
        "composer/package-versions-deprecated": "^1.11", // 1.11.99
        "doctrine/annotations": "^1.0", // 1.13.2
        "doctrine/doctrine-bundle": "^1.6", // 1.11.2
        "doctrine/doctrine-migrations-bundle": "^2.0", // v2.0.0
        "doctrine/orm": "^2.4.5", // v2.7.2
        "nelmio/cors-bundle": "^1.5", // 1.5.6
        "nesbot/carbon": "^2.17", // 2.21.3
        "phpdocumentor/reflection-docblock": "^3.0 || ^4.0", // 4.3.1
        "symfony/asset": "4.3.*", // v4.3.2
        "symfony/console": "4.3.*", // v4.3.2
        "symfony/dotenv": "4.3.*", // v4.3.2
        "symfony/expression-language": "4.3.*", // v4.3.2
        "symfony/flex": "^1.1", // v1.21.6
        "symfony/framework-bundle": "4.3.*", // v4.3.2
        "symfony/http-client": "4.3.*", // v4.3.3
        "symfony/monolog-bundle": "^3.4", // v3.4.0
        "symfony/security-bundle": "4.3.*", // v4.3.2
        "symfony/twig-bundle": "4.3.*", // v4.3.2
        "symfony/validator": "4.3.*", // v4.3.2
        "symfony/webpack-encore-bundle": "^1.6", // v1.6.2
        "symfony/yaml": "4.3.*" // v4.3.2
    },
    "require-dev": {
        "hautelook/alice-bundle": "^2.5", // 2.7.3
        "symfony/browser-kit": "4.3.*", // v4.3.3
        "symfony/css-selector": "4.3.*", // v4.3.3
        "symfony/maker-bundle": "^1.11", // v1.12.0
        "symfony/phpunit-bridge": "^4.3", // v4.3.3
        "symfony/stopwatch": "4.3.*", // v4.3.2
        "symfony/web-profiler-bundle": "4.3.*" // v4.3.2
    }
}

Previous Chapter

Next Chapter