Firewalls & Authenticator

Hey Alex,

Most probably so, "make:auth" command might become smarter in your version of MakerBundle :)

Cheers!

Hey Nathan,

Good question! I always thought they should be case sensitive, but if you say that both work for you - maybe they are not case sensitive. Or, it may depend on Symfony version. Or it may just work in some spots and does not work others :) But you're right, the convention is to always uppercase them. About the code, I believe the logic lives in RoleVoter: https://github.com/symfony/... - as you can see it clearly compare strings with strict ===, so I would say different cases won't work... unless you wrote it as ROLE_Admin in all spots that will give you check like "ROLE_Admin" === "ROLE_Admin" there :)

I hope this helps!

Cheers!

Hey Miky

Yeah that's true Symfony 5.3 has a lot of changes in Security component, and it can't be covered by some notes and honestly is not related to this tutorial 'cause it based on Symfony 4.

PS There will be a course dedicated to Symfony 5 + Security component, but I can't say any eta on it :)

Cheers!

Hey Helmis D.!

It's a good question - I was just talking about this exact thing with a friend last night :).

Inside your code (like a controller), you often write code like $this->getUser() to find the ONE user that the "person" using your site is currently authenticated as. The "main" reason to have two firewalls is that it allows you to be logged in as two users at the same time. For example, suppose you have a firewall that matches ^/admin and so when you are under /admin you log in as some "admin" user. But for any other URL on the site, you log in using some different "frontend" account. It's not a common use-case... so it's a bit hard to imagine (I would normally recommend that you have just one user and give some users admin rights to be able to access things under /admin).

The point is, if you are logged in as some AdminUser and also FrontendUser, when you call $this->getUser(), which one should be returned? In Symfony's security, for each request, you can only be authenticated as a single user. That's why, when the request starts, Symfony finds the one firewall that should be active and asks it "who is logged in?". So if you called $this->getUser() from a URL starting with /admin, you would get that AdminUser. And if you ran that same code on any other URL, you would get the FrontendUser.

That's the long... description. Most of the time, you do not need multiple firewalls (not counting the fake "dev" firewall). Inside a single firewall, you can allow the user to authenticate in as many ways as you want - like a login form, API token header, LDAP, anything. Basically, the user can then choose how to log in. But ultimately, in your code when you call $this->getUser(), you don't care how they logged in (e.g. LDAP) - you just care who they are.

Also i discovered that when we put a pattern, something like
pattern: ^/(_(profiler|wdt)|css|images|js)/
The firewall is absent(ignored?) in Symfony Profiler

That's correct! Very good attention to detail. If the one firewall that's activated has security: false it basically disables the security system entirely. If that's a problem, just remove this firewall. The only reason it exists is to help prevent people from accidentally making their app security so tight that they accidentally require authentication for URLs starting with /_profile or /_wdt... which would break the profiler and web debug toolbar... and would probably be difficult to debug. If you know what you're doing and (for some reason) want security active on the profiler, you can totally remove this and take control.

Does that help? Is there a use-case that is making you want to use multiple firewalls?

Cheers!

Thank you very much for taking the time for these explanations, I now understand how the firewall works. The ambiguities have disappeared from my head :D ☀

Hey Patrick!

Yeah, good catch! In practice (starting with 4.4.1 and 5.0.1 where a fix was done), "anonymous: lazy" should not behave in any noticeably different way than "anonymous: true". So it should be not a big deal - it's basically the same (lazy basically is the same as true). Thank you for mention it here!

Cheers!

Hey Gballocc7

To remove a bundle from a Symfony app is very easy, if you are using Symfony Flex all you need to do is remove it with composer, unless you added some specific config. The manual way would be to first remove the bundle from composer, remove the line of code which activates the bundle (inside bundles.php), then remove any config file and that would be it.

About your question. Have you checked this documentation? https://symfony.com/doc/cur...

Cheers!

Hey Roman R.!

Yep, I know this error! And you've already done the first thing correctly: double-check your namespace.

Basically, this error means that, for some reason, the App\Security\LoginFormAuthenticator service does not exist. Check the spelling of the "namespace" inside that class as well as the class name to be sure. Also, what version of Symfony are you using? If everything is setup correctly with this service, you should see it when you run:

php bin/console debug:container --show-private authenticator

Let me know what you find out - it's most likely a small typo somewhere!

Cheers!

Thank you for reply. I double check everything and there is no typo.If running that command the same error occured in console. I'm trying define authenticator as a service and in this case everything looks good but --debug:container --show-private authenticator show only this:
[0] maker.maker.make_authenticator
[1] Symfony\Component\Security\Guard\GuardAuthenticatorHandler

Hey Roman R.!

Hmm. Can you post your services.yaml code? And what version of Symfony are you using? I'm wondering if you're not using the new service auto-registration stuff and so you're using a different service id. Let me know :).

Cheers!

I'm using symfony 4.2.3
`
parameters:

services:

# default configuration for services in *this* file
_defaults:
    autowire: true      # Automatically injects dependencies in your services.
    autoconfigure: true # Automatically registers your services as commands, event subscribers, etc.

App\Controller\JsonRpcController:
        public: true
        bind:
            $jsonRpcServer: '@api.jsonrpc_server'

api.jsonrpc_reflection:
        class: App\Model\JsonRpcReflection
        arguments: ['@service_container', '@api.jsonrpc_serializer', '@annotations.reader']
        public: false

api.jsonrpc_serializer:
        class: App\Model\JsonRpcSerializer
        arguments: ['@jms_serializer', '@jms_serializer.serialization_context_factory']
        public: false

api.jsonrpc_server:
        class: App\Service\JsonRpcServer
        arguments: ['@api.jsonrpc_serializer', '@api.jsonrpc_reflection']
        public: true

api.form.login:
    class: App\Security\LoginFormAuthenticator

`

Hey Roman R.

You are missing this piece of configuration:

services:
    # makes classes in src/ available to be used as services
    # this creates a service per class whose id is the fully-qualified class name
    App\:
        resource: '../src/*'
        exclude: '../src/{DependencyInjection,Entity,Migrations,Tests,Kernel.php}'

    # controllers are imported separately to make sure services can be injected
    # as action arguments even if you don't extend any base controller class
    App\Controller\:
        resource: '../src/Controller'
        tags: ['controller.service_arguments']

So almost everything inside "src/" will be auto registered as a service. And because of that you don't need to define "api.form.login"

Cheers!

Thank you! That's works!!! But now my ide didnt know about Controllers methotds, I'm using php storm.

Have you installed Symfony plugin? And a couple others like Twig and annotations support?

Yes. I have its both and its enabled.

Hmm, try clearing the index. Go to settings -> symfony plugin -> clear index
It may do the trick :)

Already trying(((

And nothing? Sometimes by running "composer install" it get fixed. If not, try restarting PHPStorm... I'm running out of options =S

Hey @Bobby!

Haha, like your name :). Yes, the new make:auth command awesomely now gives you the new option (2) - the login form authenticator. In this tutorial (before that option existed), we were effectively choosing option (1). And then we basically build (manually) a login form system. The final result of this tutorial actually looks quite similar to what you get if you choose option (2) (but we also wanted to build it manually so we could learn along the way).

Anyways, I'm not sure I've answered your question yet :).

> will you update this later in the future when building and rendering forms

In our forms tutorial, we will *not* do any more work on the login form system. Both in this tutorial and in the updated generator, it does not use the form system. There is nothing wrong with using the form system for the login form, it's just such a simple form (and its validation is a bit different) that I prefer just using HTML forms for it. The only thing you need to remember (which we do in this tutorial and the generator also does it) is to add CSRF protection to your form.

If I still haven't answered your question - let me know!

Cheers!

So if I understand correctly, when following the tutorial for learning purposes, we should choose "Empty authenticator" when running make:auth? Is there a simple instruction set to stay in line with the course at this point with the new wizard?

Thanks!

Nevermind. Should have just watched the video and seen the instructions added. Anyone else wondering -- just keep going.

haha, no worries Aaron, sometimes we all speak too fast :p

Hey Stephane!

Ah, typo! Yes, it should be AbstractGuardAuthenticator. It's not a Sf4 thing - it's just me saying the wrong class! You will see AbstractGuardAuthenticator in the video, even if I say something different in the script. Sorry for the confusion!

Cheers!

Hey Ryan,

Thank for your reply. But why you don't use AbstractGuardAuthenticator ? It's about simplicity ?

Hey Stephane!

Good question :). We change from AbstractGuardAuthenticator to AbstractFormLoginAuthenticator because, when you're building a login form, AbstractFormLoginAuthenticator requires you to do less work. If you look, AbstractFormLoginAuthenticator extends AbstractGuardAuthenticator, but it implements a few methods for you so that you don't have to. For example, when you're building a login form, we *know* that on failure, the user should be redirected to the login page. So, AbstractFormLoginAuthenticator implements the onAuthenticationError() method so that you don't have to.

In other words, AbstractFormLoginAuthenticator is just a "helper" sub-class that allows you to do less work when you're building a login form :).

Cheers!