Guard: Joyful Authentication

I solved the problem with encoded password, I made mistake in my fixtures and I was encoding password not plain password. But I still can't find out why when i log in in toolbar I see
Loggedin: admin
Authenticated: No

Hey Andrzej!

I'm glad you solved the first problem :). About the second problem, what does your getRoles() method look like in your User class? Make sure that it *always* returns at least *one* role. If you return zero roles from getRoles(), then you will see this behavior. Let me know if that's the problem!

Cheers!

Hello, this is my getRoles() method

public function getRoles()

{

$roles = $this->roles;

$roles[] = 'ROLE_USER';

return array_unique($roles);

}

Here is screen from my toolbar

http://www.awesomescreenshot.com/image/1101770/f621f2898398db69d11601314f1bd26c

Hmm, curious - that is *not* the problem then. Does your user implement AdvancedUserInterface by chance?

I found the reason of this problem, it was cause because of setPlainPassword() and eraseCredentials() methods in User class. I found in Symfony documentation that it is good co clear plainPassword for security reasons. Commenting out $this->setPlainPassword(null); fixes the problem.

  public function setPlainPassword($plainPassword)

    {

    $this->plainPassword = $plainPassword;

    $this->setPassword(null);

    }

 public function eraseCredentials()

    {

$this->setPlainPassword(null);

    }

Hi Andrzej!

Yes, it *is* good to clear your plan password in eraseCredentials - it just makes sure that the plain password doesn't accidentally get stored anywhere, like the session. Symfony automatically calls this after you login. You just need to make sure that you don't also clear the password field :). In this case, in eraseCredentials(), I would directly set $this->plainPassword = null - instead of calling setPlainPassword(). That should also fix the problem.

Cheers and thanks for sharing!

Hi, I just posted a comment because I have the same problem (did this this sorry). But the eraseCredential don't seems to be the problem (with comment or setPlainPassword = null, the problem is still here)

Boom! I love the feedback - thanks for sharing Daniel :)

Hi there!

Really good questions :). Let me try to help:

1) I don't usually use a Symfony form for a login form - I feel it's overkill. But, it's certainly not wrong.

2) Yes, I would submit the form in getCredentials(), and then return the array of data from that method (or an object, if you have your form bound to an object).

3) How to send back the errors, is a little more difficult. If the form is not valid, I would probably save the form into the request object and then fail authentication (all in getCredentials()):

if (!$form->isValid()) {
    $request->attributes->set('login_form', $form);
}

Then, in onAuthenticationFailure(), I would do nothing: allow the request to continue to your controller. Make sure that the URL you submit your form to (e.g. /login) is the same URL that displays your login form. That way, by doing nothing in onAuthenticationFailure, the request will continue and will call your loginAction (the one that displays your form). Here, look for the Form in the Request and use it:

public function loginAction(Request $request)
{
    if ($request->attributes->has('login_form')) {
        $form = $request->attributes->get('login_form');
        $request->attributes->remove('login_form');
    } else {
        $form = $this->createForm(...);
    }

    // ... all your normal logic
}

If authentication fails, you will use the form that was stored (temporarily) on the request: this will have all the normal, bound errors.

For me - this isn't worth the trouble :). But it certainly will work just fine.

4) If you have a chain of authenticators, each of them should be authenticating in a different way - e.g. one for form login, one for API key authentication etc. So, think only your "form login" authenticator would have a form - the others would just do whatever they need to do.

I hope that helps!

Cheers!

Thanks much for your answer, it does help indeed :)

Hey arvilefvre!

That's a *great* question. It's mostly because... I hate the user provider :). Basically, the user provider should be less coupled into Symfony's security system - it actually only serves 2 purposes: (A) to help refresh your user from the sessions and (B) to load the user for the rememeber_me of for the switch_user functionality. In theory, you should not even *need* a user provider if you were creating a pure API (with no sessions).

So, when I teach security, I try to ignore the user provider as much as possible, because it's much less important than many people think (and mostly confusing).

Now, about your real question! You will definitely need a Guard authenticator for handling the incoming JWT token. Though, it's more common for you to send the token on a header, rather than read it on a cookie. Why? Because if you rely on cookies, then basically the only "thing" that can use your API is your own JavaScript. And if you're building an API *only* for your own JavaScript, you could just rely on normal session cookies and not mess with *any* API token stuff (just have the user login normally, which sets a session cookie, and then start making AJAX requests).

But anyways, if you *do* still need the full setup, then, for the first part (handling the login & pass and then sending back an API token), I would do this in a *controller* not an authenticator (though you could do it either way)? Why? The purpose of an authenticator is to *authenticate* your user. But if the purpose of your endpoint is to simply check their username/password and send *back* an authentication token, then you probably don't actually need to *authenticate* the user on that request. This situation is less about security, and it's more a pure API endpoint where the user is sending some data, and you're sending some data back. We do this exact thing in another tutorial: https://knpuniversity.com/s...

I hope that helps! Cheers!

Hi!
Thx for your quick answer :)

As for my symfony app, I guess I was not so clear, but It's actually a front web app that need to connect to another api, so I need to get a login and password from the user, send them to the api, that will send back to me a token that I need to keep to be able to call the api afterward.

I managed to make it work (thx to your article, helped me to understand the guard system better :)), I'm not sure it's the best way, but it works ^^

Hey Javier,

I think you can get current user from the $token like $token->getUser(), and then you'll be able to generate the "user_dashboard" URL in onAuthenticationSuccess().

In your controller, if you extends Symfony default controller which is "Symfony\Bundle\FrameworkBundle\Controller\Controller" - you have a shortcut to get current user object, just call $this->getUser() in your dashboardAction().

Cheers!

Hi Victor! Yes, my controller extends the default one. I'll give your suggestions a try.

Hi Victor,

I've tried the following:

LoginFormAuthenticator.php:

public function onAuthenticationSuccess(Request $request, TokenInterface $token, $providerKey)

    {

        $targetPath = $this->getTargetPath($request->getSession(), $providerKey);

        $user = $token->getUser();

        if (!$targetPath)

        {

            $targetPath = $this->router->generate('user_dashboard');

        }

        return new RedirectResponse($targetPath, [

            'user' => $user,

        ]);

    }```


UserController.php:

/**

 * @Route("/user/{id}/dashboard", name="user_dashboard")

 */

public function dashboardAction(Request $request)

{

    $user = $this->getUser();

    return $this->render('users/dashboard.html.twig', [

        'user' => $user,

    ]);

}```

However, I get the following error:

Some mandatory parameters are missing ("id") to generate a URL for route "user_dashboard".```


Any ideas?

Thanks.

Hey Javier,

Haha, of course! This error makes perfect sense ;) You have to pass User ID when you generate user_dashboard URL:

$user = $token->getUser();
$targetPath = $this->router->generate('user_dashboard', [
    'id' => $user->getId(),
]);

And btw, you don't have to pass user to the RedirectResponse, just return:

return new RedirectResponse($targetPath);

Yay!!! it works! Thanks Victor!

Awesome!!! You're welcome!

Hi Abou!

Absolutely! But, it might even be easier to use this bundle without guard: https://github.com/BeSimple.... You can see an example project created by a friend of mine here that uses this for CAS: https://github.com/rlbaltha....

Cheers!

Thank's a lot for the answer !

I've tried to use that bundle but composer complains for some incompatibility with my symfony version (3.1.4) ... :(

Anyway thank you so much for beeing so envolved and so kind to answer all ower questions !

Abou.

Ah, you're right! What a bummer! Well, hopefully you can find something else or build off of its ideas at least!

Cheers!

Hey David L. ,

If I recall correctly, you should return null in your `onAuthenticationSuccess()` and it will work out of the box. Could you try it? If it still does not work, force it with enabling use_referer option. I think it should help.

Cheers!

It didnt work, I just sit at the login page now. Here is what my main firewall looks like. I didnt have the form_login section before, i added it so I could have the use_referer option. Without that, I got an error when the controller returned null.

    main:
      pattern: ^/
      anonymous: ~
      logout:
        path: /logout
        target: /
      form_login:
        use_referer: true
        login_path: /admin/login
        check_path: /admin/login_check
      guard:
        provider: admin_user_provider
        authenticators:
          - app.authenticator.form

Yes, this is a really important detail - one that we use here on our site!

Here's the trick: use the TargetPathTrait and call the getTargetPath() method: https://github.com/symfony/.... This is new in Symfony 3.1 - but no problem: if you're on an earlier version, simply copy that small function into your code.

Here's what's going on:

A) When you try to access some secure page (e.g. /admin) and are redirected to the login page (or more accurately, the start() method in one of your authenticators redirects the user to the login page), Symfony automatically stores this URL (/admin) in the session under a very specific key.

B) The TargetPathTrait::getTargetPath() function is just a helper for you to read this key from the session.

Let me know if it works! We also do this same thing after registration - since the user might choose to register instead of logging in ;).

Cheers!

Hey Ali Karchoud!

Hmm. Try changing the checkbox name to _remember_me - that's what it should be. Otherwise, if it still doesn't work, if you can push a test repository to GitHub with the issue, I can take a look.

Cheers!

ty sir for the answer i already have the checkbox with that name which is the default remember_me parameter.
well since the project i'm working on is a company project i can't publish it on github and i don't have access to private repo but i can give u the code snippets from authenticator and the firewall and the view

Yo Ali Karchoud!

Here's what we can do :). Create a fork of https://github.com/symfony/... and add your authenticator and security configuration there to repeat the problem. Then, you can share that repository with me :). If you only give me the form authenticator, firewall and view code, then *I* will need to take the time to integrate it into the symfony-demo to try to repeat the problem. So if you can do that for me, I can return the favor by taking some time to help debug the issue.

Cheers!

Ty sir i appreciate your help I’m busy at the moment so I will do that later and share with you the link. What you are offering is a real favor weaverryan

Hey Geoff Maddock!

This is a perfect use-case for Guard authentication :). Ok, about your question. For LDAP, you probably already sent the credentials to LDAP inside getUser() in order to authenticate and get the user information, correct? If that's true, then you've effectively already checked the user's credentials then. This means in checkCredentials(), you can just return true.

Fun fact: you could always do everything in getUser() and just hardcode a return true in checkCredentials(). We made 2 separate methods just to help "guide" you. And also, the user will get a slightly different error message based in which method authentication fails in... but you can also throw a CustomUserMessageAuthenticationException to create your own custom message from anywhere :).

Let me know if this helps!

Cheers!

Thanks for the followup. In my case, I did not query LDAP in getUser, just the User entity repo. In my case, all users (usernames) are in the User Entity database. So I don't have to get them from the LDAP server. But I do need to validate the passwords of some of the users against LDAP.

So can I inject the LDAP class (Symfony\Component\Ldap\Ldap) into the LoginFormAuthenticator constructor and then build and call the bind there? Or is there another service that makes more sense to use?

Attempting to use use (Symfony\Component\Ldap\Ldap), inside of the checkCredentials such as:

               ...
               // build the correct username
              $login_username = sprintf('DOMAIN\%s', $user);
              $username = $this->ldap->escape($user, '', LdapInterface::ESCAPE_FILTER);

               // check LDAP server if LDAP user
               if ($this->getApp() == 'LDAP') {
                // if the bind fails, this throws 500 - Invalid credentials
                $this->ldap->bind($login_username, $password)
                // if the bind succeeds, i can return true since it successfully authed
                return true;
                }
                ...

Interestingly in this case, if the username and password don't match, it throws a 500 error and states "Invalid Credentials", which seems right although I'd like to catch that error. So that does work, but doesn't seem like the right way of doing things.

I saw LdapBindAuthenticationProvider but it wasn't clear how I'd call that.

Yo Geoff Maddock!

Ah, ok - it's much more clear now. And I think you're quite close. I haven't used Symfony's Ldap component directly yet, so some of my recommendations might not be quite right. But yes, I *believe* that using this Ldap class is the correct one. And if I'm reading the code correctly, you should catch this exception: https://github.com/symfony/...

On the catch, just return false. It may seem weird, but that class is designed to throw an exception in case binding fails. So, we *do* need to catch it and return false so that the proper flow can go forward. The LdapBindAuthenticationProvider is buried too deep in the ldap security system for us to use it from Guard. But... check this out! They *also* use bind() inside a try-catch: https://github.com/symfony/.... I'd say that 100% validates your approach :).

Cheers!

Awesome, thanks for the assist. I think I have my authenticator working the way I need it to work (including re-encrypting old sha1 passwords automatically on login).

One last, and merely tangential question - what's the best practice for accessing a parameter from a class like my custom LoginFormAuthenticator? I'd like to define the format for my LDAP login somewhere globally, like in parameters.yml, but I won't be able to access that value without the container.

Hey Geoff Maddock!

Awesome! Nice work!

About your question, If I understand it correctly, you can pass parameters through your __construct function just like any services. The only differences is that parameters (or any scalar values) can't be autowired, so you'll need to wire them up manually - see https://knpuniversity.com/screencast/symfony-3.3/named-arguments.

Oh, and I'd recommend only putting that config in parameters.yml if the format will change from server to server (e.g. it's different locally versus production, like a database password). If it does not change, and you just want to avoid hardcoding it in your class, then add it as a parameter in services.yml. Then, it will be committed to the repository and you won't need to worry about managing that config separately on all servers.

Cheers!

Hey Thomas Baumgartner!

Ah, awesome! Thanks for sharing this solution - it's very clever!

About the impersonation, it should just work - it's independent of whether you're using Guard or some other authentication system. There are two things you should look at: (A) Make sure you have the switch_user key configured under your firewall and (B) make sure you "user provider" is setup correctly (since the loadUserByUsername method is used to actually find and load the new user when you switch).

If that doesn't help, let me know the error - it may spark another idea :).

Cheers!

Thank you Ryan!
I'm sorry to have bothered you with that. Turned out that it's not an impersonation problem, but has rather something to do with firewalls / access_control / role_hierarchy. I also have different routes for admin_login / employee_login, same with login_check and logout, but I am using the same UserProvider and database table for both. Now the strange thing is that I am able to log in into both araeas of the site with the same admin user (as for the role_hierarchy is granting me this), but I am not automatically logged in as employee, when I log into the admin area. (and I think thats the reason why impersonation cannot work either). So the question is, what makes the tokenStorage to be restricted to one area/acl-path only? (Interestingly, if I log out from one of the areas, I am logged out from both). Below my security.yml:

    firewalls:
        admin:
            pattern: ^/admin/
            anonymous: ~
            guard:
                authenticators:
                    - app.admin_login_authenticator
            logout:
                path: admin_logout
                target: admin_login
        employee:
            pattern: ^/employee/
            anonymous: ~
            guard:
                authenticators:
                    - app.employee_login_authenticator
            logout:
                path: employee_logout
                target: employee_login
            switch_user: ~

    access_control:
        - { path: "^/admin/login", roles: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: "^/employee/login", roles: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: "^/admin/", roles: [ROLE_ADMIN, ROLE_PROJECT_MANAGER] } 
        - { path: "^/employee/", roles: [ROLE_EMPLOYEE] }

    role_hierarchy:
        ROLE_DEVELOPER: [ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH]
        ROLE_ADMIN: [ROLE_PROJECT_MANAGER, ROLE_ALLOWED_TO_SWITCH]
        ROLE_PROJECT_MANAGER: [ROLE_EMPLOYEE]
        ROLE_EMPLOYEE: []

UPDATE: hah, got it! It's the firewall configuration. Not sharing the token between firewalls totally makes sense, just not in my case. I only had to add a context property containing the same string to each of my firewall configuartions and I'm done. Token shared, impersonation works. Thank you so much again Ryan, feel free to delete this post, if you consider it too much off topic in this place.

Great find and fix Thomas! Yes, multiple firewalls don't share *anything*... unless you find that nice context property :). Cheers!