Context Builder: Dynamic Fields/Groups

Thank you for your feedback!

Cheers!

Hi Chloé!

Excellent, crazy question - I like it! So, this is something that we'll talk about in the next tutorial - https://symfonycasts.com/screencast/api-platform-extending - but it will be a few more days or even a week+ before it's out. So let me give you the preview:

A) validation & security are a blurry line. Is what you want to do security... or validation? It's sort of both :p

B) What I do is use security to deny access entirely to operations: like, you do or don't have access to the PUT method for this user. I use validation for everything else: where a user can/cannot change a certain field to a certain value.

C) So, in the next tutorial, we will create a custom validator, attach it to the ApiResource (attach it above the class if you need access to the entire object, or attach it just to a specific field if you only need to read that one field), inject the Security service into that validator, then go crazy by doing whatever checks that you want. One key ingredient to this is that you will need to know which fields were changed on the request. What I means is, you can't simply look at $user->getRoles() in the validator and say "it looks like the roles changed!" because... maybe they did... or maybe the request didn't touch the roles at all. What I will do in the next tutorial is get the "original data" of my entity (User in your case) from Doctrine and compare it with the new data. For example:

// in the validator, assume there is an entityManager property

// will be an array of the data from the query, before the data was changed
// will be empty for new objects
$originalData = $this->entityManager->getUnitOfWork()->getOriginalEntityData($user);
$originalRoles = $originalData['roles'] ?? [];

if ($originalRoles == $user->getRoles()) {
    // the roles did not change
    return;
}

// the roles DID change! Do some checks to see if that was allowed

Also:

so then when we dynamically add "admin:write" to the denormalization context, and thus allowing the admin user to update their roles... it allows only this user to update their own roles, right

Correct. admin:write means only an admin can edit that field... and because the only user that has access to a PUT request at all is "myself", it means that only an admin could modify the roles field... and they could only modify their own field :p.

I hope that helps!

Hi @weaverryan!
Thanks a lot for your fast and complete answer, as always it's very interesting and really helps. :D with that in mind I'll think a bit more about what I want to achieve/how I want to achieve it, and wait patiently until the release of the next tutorial.
Cheers!

Hey Chloé

Just to let you know that the ApiPlatform episode 3 course it's been actively released now https://symfonycasts.com/sc...

Cheers!

Hey MolloKhan

Thanks, actually I think the chapter that would interest me most regarding my question is not out yet (I'm guessing it would be the 4th or 6th)... but of course I'll take a look at the first three that are out. :)

Hey @couteau!

Excellent question! So... it depends on what you want :). In theory, by throwing a 403, you are:

A) GOOD: Giving the user more information about why they can't set this field (that's a good thing! Maybe they forgot to authenticate)

B) BAD: You are potentially exposing that this field exists. That's not the biggest deal ever, but if this IS truly an admin-only field, you're exposing the fact that these fields DO exist - e.g. if I send a non-existent field called "bar", it's simply ignored. But if I send a field that DOES exist, but is protected, then I would suddenly get a 403.

So... it depends on what you want :). How would you throw a 403 instead? Hmm. A few options come to mind:

1) You could create a custom denormalizer that looks at the input array, sees if the field is present, checks if the admin:write group is present, and if the field IS present, but the group is not, throw an AccessDeniedException (the one from the security system). This is pretty "hands on", you are effectively duplicating your work in the context builder. Basically, you now have a context builder to add the admin:write group... but then you again manually check for that field in your custom denormalizer. You could probably also do something similar via an event listener.

2) By default, in general, Symfony's serializer ignores extra fields. However, you can change this behavior and tell it to throw an exception instead - https://symfony.com/doc/current/components/serializer.html#deserializing-an-object - you do this by adding setting an AbstractNormalizer::ALLOW_EXTRA_ATTRIBUTES key to false on the $context, which you could do in your context builder. This will cause a ExtraAttributesException to be thrown, which I believe will map to a 500 error. However, you could map it to a 403 via the api_platform config: https://api-platform.com/docs/core/errors/

So yes, this is possible - but it's not the "normal case" I think, so implementing it will take a bit of work :).

Cheers!

Hey Philippe B.!

Thanks for sharing! This makes sense to me - I actually like your longer admin groups, instead of the generic admin:read. When I was writing the tutorial, I gave a lot of thought to these group names - and also talked to Kevin Dunglas about the general idea - because I also like these auto-groups, butI was indeed afraid of conflicts like this. This is one that I honestly didn't think of.

So, you have no complains from me! I like it!

Cheers!

Hey Sardar K.!

I don't think I fully understand your situation, but I think I understand enough to try to answer ;). Let me start with the easy answer:

but simply i want to compare current logged user with all other users inside decorator (contextBuilder)

You are able to access the currently-authenticated user by autowiring a new Security $security argument and then using that to get the currently-authenticated user.

But... I'm not sure this was really your question. Can you give me a concrete example with real entity names and real API request (e.g. when I login as UserA and make a GET request to /api/products ...)? My guess is that you want to actually filter some collection result: make it so that one user sees a certain sub-set of "items" and another sees a different sub-set. If so, I'm not sure that a context builder will be the answer. But let me know the full situation and then we can decide :).

Cheers!

Thank you for your answer

actually the problem solved with chapter 29 custom normalizer

but i have a new question i will try my best to explain correct way this time
i will add code first the i will explain what really i want.

App\Entity\User

/**
 * @ORM\Entity(repositoryClass="App\Repository\UserRepository")
 * @UniqueEntity("username")
 * @UniqueEntity("email")
 * @ApiResource(
 *     itemOperations={
 *          "get",
 *          "put" = {
 *              "access_control"="is_granted('ROLE_ADMIN') or (is_granted('IS_AUTHENTICATED_FULLY') and object == user)",
 *              "access_control_message"="Only Admin or the owner can edit this field",
 *              "denormalization_context"={"groups"={"user:update"}}
 *          },
 *      },
 *     collectionOperations={
 *          "get",
 *          "post" = {
 *              "denormalization_context"={"groups"={"user:write"}}
 *          }
 *      },
 *     normalizationContext={
 *          "groups"={"user:read"}
 *     }
 * )
 */
class User implements UserInterface
{
    public const ROLE_ADMIN = 'ROLE_ADMIN';
    public const ROLE_MEMBER = 'ROLE_MEMBER';
    public const ROLE_COLLECTOR = 'ROLE_COLLECTOR';
    public const ROLE_WEBMASTER = 'ROLE_WEBMASTER';

    const DEFAULT_ROLES = [self::ROLE_MEMBER];

    public const ROLES = [
        ['ROLE_PRESIDENT'],
        ['ROLE_ADMIN'],
        ['ROLE_MEMBER']
    ];

    /**
     * @ORM\Id()
     * @ORM\GeneratedValue()
     * @ORM\Column(type="integer")
     *
     * @Groups("user:read")
     */
    private ?int $id = null;

    /**
     * @ORM\Column(type="string", length=100)
     * @Groups({"user:read" , "user:write"})
     * @Assert\NotBlank()
     * @Assert\Length(min="4")
     */
    private ?string $username = null;

    /**
     * @ORM\Column(type="string", length=100)
     * @Groups({"admin:read", "owner:read", "user:create", "user:update", "admin:write"})
     *
     * @Assert\NotBlank()
     * @Assert\Email()
     */
    private ?string $email = null;

  /**
     * @Groups({"user:write", "user:update"})
     *  @SerializedName("password")
     * @Assert\NotBlank()
     * @Assert\Length(min="8")
     */
    private ?string $plainPassword = null;

  /**
     * @ORM\Column(type="simple_array", length=200, nullable=false)
     * @Groups("admin:read")
     */
    private array $roles = [];

/**
     * @ORM\ManyToOne(targetEntity="App\Entity\Association", inversedBy="users", cascade={"persist", "remove"})
     * @Groups({"user:read"})
     */
    private ?Association $association = null;

  // setter and getters...<spoiler></spoiler>

App\Entity\Association

/**
 * @ORM\Entity(repositoryClass="App\Repository\AssociationRepository")
 * @UniqueEntity("name")
 * @ApiResource(
 *     itemOperations={
 *          "get"
 *     },
 *     collectionOperations={
 *          "get"
 *     }
 * )
 */
class Association
{
    /**
     * @ORM\Id()
     * @ORM\GeneratedValue()
     * @ORM\Column(type="integer")
     */
    private ?int $id = null;

    /**
     * @ORM\Column(type="string", length=50)
     * @Groups("user:read")
     */
    private ?string $name = null;

    /**
     * @ORM\OneToMany(targetEntity="App\Entity\User", mappedBy="association")
     * @ApiSubresource()
     */
    private  $users;

  // setters and getters

so as you can see one Association is having many users that mean each Association can have their own Admin
so what i want that admin can modify email or any other thing only user from the same Association as the admin himself
just like FACEBOOK GROUP admin of the group can only delete or block user from his group not from the group someone else.

i tried with DeserializerInterface but i couldn't achieve what i wanted

so i hope it is clear this time
if not i'm too bad. :)

Hey Sardar K.!

Let me see if I understand correctly :). Let's suppose that

1) UserA is the admin or AssociationA.
2) UserRyan is a member of AssociationA
3) UserSARDAR is a member of AssociationB

In this situation, UserA should be able allowed to edit the email (or other data) of UserRyan. But UserA should not be able to edit the email or UserSARDAR. Correct?

If I'm right, then you should protect this with a custom voter put operation on the User. Something like this (instead of what you have currently):

 * @ApiResource(
 *     itemOperations={
 *          "get",
 *          "put" = {
 *              "access_control"="is_granted('EDIT_USER', object)",
 *              "access_control_message"="Only Admin or the owner can edit this field",
 *          },
 *      },
// ...

Then you will create a class like we do in this chapter - https://symfonycasts.com/screencast/api-platform-security/access-control-voter

This will allow you to do any checks you need:

A) Check to make user the current user is authenticated
B) If the currently-authenticated user === the user that's being edited (someone is editing their own information) allow it
C) If the user that's being edited is related to an association AND the currently-authenticated user === the admin of that association, allow it

There is one small "strange" thing with your data setup. It seems that you are determining if a user is a "member", "president" or "admin" or an association via roles on the User. I would not do it that way, just because there are simpler options. I would do one of the following:

1) Add a "membershipType" string field on User that is set to either "member", "president" or "admin". It doesn't make sense to use roles unless you are ever going to do something like is_granted("ROLE_PRESIDENT") where you are asking "is this user the president of any association in general?"... which I don't think you will be doing. And so, that string field is a bit simpler than storing the value in the roles array.

2) If users could actually belong to multiple associations, then you could create a AssociationMembership table that has a ManyToOne to User and Association (instead of relating User and Association directly to each other). If you had this setup, I would then put that membershipType field on this AssociationMembership entity. That would allow a user to be a president of one association, but only a member of a different one.

Cheers!

Hey Anas,

Could you explain a bit more, where do you think a fault? Or better, could you link us to specific code block where you think we have an error? I didn't see "false === $normalization" checks in this chapter.

Cheers!

Hey Bohdan,

Agree, in the video we change it to the "admin:write", I updated the code block in https://github.com/SymfonyC...

Thank you for reporting this!

Cheers!

Hey Jarrod

Probably you will have to add the ROLE_ADMIN manually to the first user, or you can code a Symfony command to update/add roles to a specific user. It depends on your needs but if you don't need anything fancy, I would rather do it manually and save some time.

Cheers!