Cover of the book Symfony 5: The Fast Track

Symfony 5: The Fast Track is the best book to learn modern Symfony development, from zero to production. +300 pages showcasing Symfony with Docker, APIs, queues & async tasks, Webpack, SPAs, etc.

  1. Home
  2. Blog
  3. New in Symfony 3.2: User value resolver for controllers

New in Symfony 3.2: User value resolver for controllers

July 13, 2016 Avatar of Javier Eguiluz Javier Eguiluz

Warning: This post is about an unsupported Symfony version. Some of this information may be out of date. Read the most recent Symfony Docs.

Contributed by
Lynn van der Berg
in #18510.

In Symfony applications, controllers that make use of the base Controller class can get the object that represents the current user via the getUser() shortcut:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
use Symfony\Bundle\FrameworkBundle\Controller\Controller;

class DefaultController extends Controller
{
    public function indexAction()
    {
        $user = $this->getUser();
       // ...
    }
}

In the past, you could also get the current request object with the getRequest() shortcut, which was deprecated in Symfony 2.4 in favor of the Request type-hint:

1
2
3
4
5
6
7
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\HttpFoundation\Request;

class DefaultController extends Controller
{
    public function indexAction(Request $request) { ... }
}

In Symfony 3.2, we've added a new user resolver that allows to get the current user in any controller via type-hinting and we deprecated the Controller::getUser() shortcut, which will be removed in Symfony 4.0:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\Security\Core\User\UserInterface;

class DefaultController extends Controller
{
    // when the user is mandatory (e.g. behind a firewall)
    public function fooAction(UserInterface $user) { ... }

    // when the user is optional (e.g. can be anonymous)
    public function barAction(UserInterface $user = null) { ... }
}

This feature uses the argument resolver extension mechanism that was introduced in Symfony 3.1. This mechanism allows to register your own value resolvers for controller arguments.

Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.

New in Symfony 3.2: User value resolver for controllers symfony.com/index.php/blog/new-in-symfony-3-2-user-value-resolver-for-controllers

Tweet this

Comments

Angel Koilov said on Jul 13, 2016 #1

Cool :)
These mini update notifications posts are pretty cool.

Am I the only one seeing more changes in 3.1 -> 3.2 than in 2.8 -> 3.0 :)

Javier Eguiluz Certified said on Jul 13, 2016 #2

@Angel you are right about the number of updates. The reason is that 3.0 contained zero new features (it only removed the features marked as deprecated in 2.8). We published just one "New in Symfony 3.0" article explaining this: http://symfony.com/blog/new-in-symfony-3-0

Robin Chalas said on Jul 13, 2016 #3

A great feature!

Thomas Schulz said on Jul 13, 2016 #4

Why are you moving away from using base Controller class methods and pushing the injection of user, request, etc.?

Sullivan SENECHAL said on Jul 13, 2016 #5

Great addition!

Can `UserInterface` type be changed by a custom one?

Christophe Coevoet said on Jul 13, 2016 #6

@Sullivan no it cannot, because a typehint on your User entity would be ambiguous whether you want to get the User object corresponding to the current logged in user or the User object corresponding to a request attribute (param converters) so supporting child classes could have broken BC.

Tomáš Votruba said on Jul 13, 2016 #7

I am very happy to see this service-DI approach propagation over helper methods coupled to some base class.

This can be used in any service with ease.

Great job!

Alex Rock Certified said on Jul 14, 2016 #8

I find this feature to be cool, but I don't understand why it's so different than `$this->getUser();`... Plus, as you always have to implement your own user class, most of the time you won't be able to take benefits from proper IDE auto-complete, whereas you can override phpdoc for the user like this:
`
/** @var MyUserClass $user */
$user = $this->getUser();
`
Which is better for autocompletion.

Gregor Harlan said on Jul 14, 2016 #9

I always use this docblock for my base controller class which extends the symfony base controller:

/**
* @method MyUserClass getUser()
*/

So I got autocompletion for the user methods in all my controller classes.

Matt said on Jul 14, 2016 #10

Assuming you have doc blocks on all your functions (which you should), you'd include this:

* @param UserInterface|MyUserClass $user

I agree that injecting the user object as a parameter, instead of calling $this->getUser(), feels cleaner and easier to test.

Piero Recchia said on Jul 15, 2016 #11

I prefer DI over inheritance, and not only is cleaner and easy to test but in the future with this params resolver there's no need for extend Base Controller

Muhammad Surya Ihsanuddin said on Jul 17, 2016 #12

Can i use UserInterface and Request both on controller parameter in same time like

```
indexAction(UserInterface $user, Request $request) {}
```

Claudio Zizza said on Aug 4, 2016 #13

The Link "argument resolver extension" leads to 404.

Everything that result in less methods in BaseController is a win.

Alex Rock Certified said on Aug 23, 2016 #14

Even with the different arguments, I still don't understand why it's not "good" to have something like $this->getUser();

:/

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.