Securing Our User Endpoint - Part 3

This video is available to view for members only.

Click here to Join!

Already a member?


In this video we are continuing on with securing our User resources, this time implementing the Symfony Voter that will participate in authorisation checks on requested resources.

In the previous video we covered how there is the concept of a Restricted\UserRepository which will pass any requested object off to an authorisation check before returning the requested resource.

Let's take a look at the code:


// src/AppBundle/Repository/Restricted/UserRepository.php

namespace AppBundle\Repository\Restricted;

use AppBundle\Repository\UserRepositoryInterface;
use AppBundle\Repository\Doctrine\UserRepository as DoctrineUserRepository;
use Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException;
use Symfony\Component\Security\Core\Authorization\AuthorizationCheckerInterface;

class UserRepository implements UserRepositoryInterface
     * @var DoctrineUserRepository
    private $userRepository;
     * @var AuthorizationCheckerInterface
    private $authorizationChecker;

     * UserRepository constructor.
     * @param DoctrineUserRepository        $userRepository
     * @param AuthorizationCheckerInterface $authorizationChecker
    public function __construct(
        DoctrineUserRepository $userRepository,
        AuthorizationCheckerInterface $authorizationChecker
        $this->userRepository = $userRepository;
        $this->authorizationChecker = $authorizationChecker;

     * @param $id
     * @return mixed
    public function find($id)
        $user = $this->userRepository->find($id);

        $this->denyAccessUnlessGranted('view', $user);

        return $user;

     * @param        $attribute
     * @param null   $object
     * @param string $message
    protected function denyAccessUnlessGranted($attribute, $object = null, $message = 'Access Denied')
        if ( ! $this->authorizationChecker->isGranted($attribute, $object)) {
            throw new AccessDeniedHttpException($message);

In the previous video we covered how we would really delegate the responsibility of finding an object over to the injected DoctrineUserRepository instead of re-implementing the logic in this class also.

We need to do this as before we can check if the currently logged in User has access to the requested object - a User resource in this instance - it is necessary to actually retrieve the requested User data from the database.

Once we have that User object (thanks to a Doctrine entity repository, in our case) we can verify - somehow - that the currently logged in User should have access to view the requested User data.

How can we do this?

Using a Symfony Voter is one particular method we could use here. There are likely other methods, as Users are a somewhat different case to most any other resource.

For the sake of standardisation I am going to show the way I use with all other resources in this project - which is to retrieve the requested object from the database and then call a vote against it.

The voting code is:

     * @param        $attribute
     * @param null   $object
     * @param string $message
    protected function denyAccessUnlessGranted($attribute, $object = null, $message = 'Access Denied')
        if ( ! $this->authorizationChecker->isGranted($attribute, $object)) {
            throw new AccessDeniedHttpException($message);

We covered the service definition for this in the previous video write up, but here it is again for reference:

# app/config/services.yml

        class: AppBundle\Repository\Restricted\UserRepository
            - "@crv.repository.doctrine_user_repository"
            - "@security.authorization_checker"

However, we haven't yet updated the UserController to take advantage of anything we have done in the previous two videos. Let's go ahead and update the UserController now:


// src/AppBundle/Controller/UsersController.php

namespace AppBundle\Controller;

use AppBundle\Handler\UserHandler;
use FOS\RestBundle\View\View;
use FOS\RestBundle\Controller\Annotations;
use FOS\RestBundle\View\RouteRedirectView;
use FOS\RestBundle\Controller\FOSRestController;
use FOS\RestBundle\Routing\ClassResourceInterface;
use Nelmio\ApiDocBundle\Annotation\ApiDoc;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Form\FormTypeInterface;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Exception\MethodNotAllowedHttpException;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;

 * Class UsersController
 * @package AppBundle\Controller
 * @Annotations\RouteResource("users")
class UsersController extends FOSRestController implements ClassResourceInterface
     * Get a single User.
     * @ApiDoc(
     *   output = "AppBundle\Entity\User",
     *   statusCodes = {
     *     200 = "Returned when successful",
     *     404 = "Returned when not found"
     *   }
     * )
     * @param int   $userId     the user id
     * @throws NotFoundHttpException when does not exist
     * @return View
    public function getAction($userId)
        $user = $this->getUserHandler()->get($userId);

        $view = $this->view($user);

        return $view;

     * @return UserHandler
    private function getUserHandler()
        return $this->container->get('crv.handler.user_handler');

Finally, the the first step in the chain has been created.

Let's take a look back at the Behat scenarios that this should cover:

    Given there are Users with the following details:
    | uid | username | email          | password |
    | u1  | peter    | | testpass |
    | u2  | john     |  | johnpass |
   #And there are Accounts with the following details:
   # | uid | name     | users |
   # | a1  | account1 | u1    |
   # And I am successfully logged in with username: "peter", and password: "testpass"
    And when consuming the endpoint I use the "headers/content-type" of "application/json"

  Scenario: User can GET their personal data by their unique ID
    When I send a "GET" request to "/users/u1"
    Then the response code should 200
     And the response header "Content-Type" should be equal to "application/json; charset=utf-8"
     And the response should contain json:
        "id": "u1",
        "email": "",
        "username": "peter",
        "accounts": [
            "id": "a1",
            "name": "account1"

  Scenario: User cannot GET a different User's personal data
    When I send a "GET" request to "/users/u2"
    Then the response code should 403

  Scenario: User cannot determine if another User ID is active
    When I send a "GET" request to "/users/u100"
    Then the response code should 403

We're definitely going to get those 403 status codes now, as the voter is going to block off any unauthorised access.

But we've broken our first test.


Well, as part of the vote, the voter will be passed the token from which it can get access to the currently logged in user.

Only... we aren't logged in. We've commented that bit out :)

To make that work, we need to implement login. And for that we are going to use LexikJWTBundle. We'll configure that in the next video, and get login using JWT's working for our API.

Code For This Course

Get the code for this course.

Share This Episode

If you have found this video helpful, please consider sharing. I really appreciate it.

Episodes in this series

# Title Duration
1 Project Introduction 17:13
2 Setting Up Our Development Environment 05:08
3 Installing Symfony 3, Behat, and more 13:53
4 User Feature - Part 1 17:47
5 User Feature - Part 2 07:51
6 Talking English To Your Computer 11:05
7 Teaching Your Database To Forget 07:42
8 Creating User Data From Behat Background - Part 1 14:44
9 Creating User Data From Behat Background - Part 2 11:33
10 Creating A Custom RestApiContext 17:44
11 Our First Passing Behat User Scenario 12:01
12 Our Next Passing Step 13:10
13 Securing Our User Endpoint - Part 1 17:17
14 Securing Our User Endpoint - Part 2 24:27
15 Securing Our User Endpoint - Part 3 24:47
16 Log In To A Symfony API With JWTs (LexikJWTAuthenticationBundle) 11:02
17 Implementing PATCH for Users 18:17
18 Improving our API User Experience 13:59
19 GET a Collection of Accounts 12:15
20 POSTing in New Accounts 14:34
21 PUT and PATCH for Accounts 12:14
22 How To DELETE Existing Accounts 05:11
23 File Feature Overview 11:40
24 File - Using Existing Resources as Boilerplate 15:17
25 File POST 14:53
26 Fixing A Bug In POST Guided By Behat 12:50
27 Wrapping Up With File DELETE 07:47