Fetch the User Object

Hey Stephane

Which Symfony version are you using?
In Symfony4 AbstractController is not final, but we don't extend from it anyways, we extend from Controller.php. If you keep seeing that message is because you are overriding the getUser() method when you should not.

Cheers!

Hey MolloKhan,
Thank for your reply.

I use Symfony 4.1.5. I have only follow the tip of Ryan about BaseController.

Oh yes, you can extend from the "AbstractController" class, it's totally ok to do that (and probably it's better). About the deprecation message, I just tried it and yes, I do see that message too but I'm not totally sure if we can just ignore it. I'll ask Ryan about it but it may take some time to get an answer back.

Cheers!

Hey MolloKhan!

Great catch! I didn't realize that these methods had been marked as final! I talked internally about it, and here is a better solution:

// ....

use App\Entity\User;

// ...

/**
 * @method User getUser()
 */
class BaseController extends AbstractController
{
}

Basically, you don't need to override getUser() in order to "advertise" that it returns some other object. You can instead use this nice @method trick. You get the same result, but no deprecation.

Thanks again for the report!

Hey EarlyBird,

I suppose you're talking about this comment https://symfonycasts.com/sc... - do you want to inject the current logged in user in your form type? Am I correct? Well, you can still use that solution I said in the first comment - pass the current user as option to the form type. I suppose you create those dynamic form types in a controller, so you can easily fetch the current user with $this->getUser() in the controller.

Otherwise, use dependency injection to inject the Symfony\Component\Security\Core\Security into your form type, and you should be able to fetch the current user via $this->security->getUser(); inside.

I hope this helps!

Cheers!

Hey EarlyBird!

Yes, you can do it. You can pass any options you want to the buildForm() method, see the 2nd argument called $options. It depends on your form, if your form is based for User object, you can do it out-of-the-box calling $options['data']. Otherwise, you can pass any data you want as options when you create your form type.

Cheers!

Hey @wuwu!

I like that you're wondering what $this->getUser() really does :). Check out this chapter: https://symfonycasts.com/screencast/symfony-security/user-in-service

Cheers!

Hey Tomasz,

Thank for this tip! Btw, if you can share a link to the docs where you found this feature - would be awesome! Yeah, it makes sense to use "?UserInterface" type-hint on those pages where user might be anonymous, good point! Otherwise, you will have problems. Or, probably "create(UserInterface $user = null)" might work too, but I have not tried it yet. But anyway, "?UserInterface" makes more sense here.

But this is interesting that it's buggy in combination with isGranted(). Are you sure it's related to injecting the current user? If you fo not inject the current user - isGranted() starts working well again? Because, at the first sight, injecting the current user and isGranted() annotation has nothing in common except using current logged in user from the internals. Though I'm do not know the internal code that's responsible for annotations.

Btw, what about using "$this->isGranted('IS_AUTHENTICATED_REMEMBERED')" in the beginning of your create() method instead of @isGranded annotation? Does it works well or also have problems?

Cheers!

It seems to me there is no information about this feature in the documentation. There is blog post about it: https://symfony.com/blog/ne...

There is a bug in combination of @IsGranted (specifically annotation, no AbstractController shortcut) and UserInterface type hint without nullable. It makes sense to use UserInterface type hint without nullable and without default "null" value if @IsGranted enforces user session. Technical details about bug are described here: https://github.com/sensiola... Basically @IsGranted is interpreted AFTER preparation of controller arguments, this causes problem. My pull request tries to fix it: https://github.com/sensiola...

Hey TomaszGasior!

Yea, one of the biggest reason that it's not documented (or at least, poorly documented) is that I don't really like this feature (though other people definitely disagree with me!). We already have a lot of magic in the controller, and I didn't see the benefit of adding yet-another "magic" resolution of controller arguments. Also, because you have to type-hint UserInterface, your editor doesn't will only auto-complete methods on that interface - not any custom methods you have. That's also true with the getUser() shortcut, but you can work around that by adding documentation to a base controller (like we do in this tutorial). This is probably also why that bug exists - not a lot of people use this way of getting the user.

So, I hope that at least explains a bit about the missing documentation and the bug. But, let me know!

Cheers!

Hey boykodev

Aha! Nice catch man. I already fixed the note

Cheers!