Creating a Login Form (Part 1)

Hey Scott!

Yea, I think this issue :). Actually, when you login, you *are* logged in for a moment, but then you lose the login on the next request. You can see this by setting intercept_redirects (https://github.com/symfony/... to true temporarily. After login, it will stop and *not* redirect you. And on this page, you'll see that you *were* successfully authenticated.

So, why is this lost on the next request? It's a gotcha (one that hopefully we can make less of a gotcha in the future - it's tricky). Three things happen at the beginning of each request after you're logged in:

A) The User object is deserialized from the session (that's when the User::unserialize method is called)

B) That User object is used to query for a new one: refreshUser is called on your user provider. Usually, you use the id of the serialized User to query for a fresh one.

C) (and here's the tricky one): the deserialized User object is compared with the fresh User object. If they are not deemed "equal", you are logged out. What??? The purpose of this is to allow you to change your password in the database and cause a remote bad person who has stolen your account to be automatically logged out. Basically, you need to make sure that several properties are serialized: username, password, salt (not relevant in your case) and any values that fuel the AdvancedUserInterface methods. As long as these are serialized, then the two User objects will look equal. Here's the code in Symfony that checks this: https://github.com/symfony/....

The most common problem is not serializing some properties you need in User::serialize(). But you did a perfect job! The issue is smaller, and I've described it more on this pull request: https://github.com/onlinesp...

I hope that helps! Also, to make your code simpler, you could delete your UserProvider (and associated code in UserRepository) and instead user the built-in entity user provider (you have some commented-out code for this - it looks like you *were* using it. Anymore, I don't really think that *anyone* needs a custom user provider if they're using Doctrine. If you need to do some crazy query for your User in your "authenticator", just call a custom method on your repository. You're already doing this: https://github.com/weaverry...

Also, you can remove the "form_login" stuff if you're using guard as your login form - it's just not needed. You *will* still you need your login routes, template, etc.

Cheers!

I really appreciate your help with this and all the other stuff you do for the community!

I thought that was what the application was doing (logging in and logging back out) but didn't know about the intercept_redirects setting. Your explanation makes sense.

I merged the change in the pull request, deleted the UserRepository and references to it, and removed the "form_login" stuff and everything is working. Yay!

Now off to implement API and Facebook authentication!

Wow, that's awesome!!!

It's on my todo list to add some things for social (Facebook) auth, but I haven't gotten there quite yet. I *do*, however, have a WIP code implementation of Facebook auth using the KnpGuardBundle (which is very close to the core Guard). If it's helpful, you can see that final code here: https://github.com/knpunive..., with step-by-step commits: https://github.com/knpunive...

Good luck!

Thanks again!

I was able to implement Login, API, and Facebook authentication. Initial versions here: https://github.com/onlinesp...

Wouldn't have been able to finish this so quickly without your help!

That's awesome! Thanks for sharing your efforts!

I can ask myself: The article must be a bit deprecated because knpu_guard is no longer accepted. If you have this problem use "guard" instead as a key in the security.yml file

Hey Sergio Valije Guiadanes!

Yes, you're right! Guard was accepted into Symfony's core in version 2.8 - before, that, it was a third-party bundle and was configured via knpu_guard. There are a few other differences as well with the new version in core - so just be careful! It's on our list to properly update our Guard tutorial for the version in Symfony's core.

Cheers!

Oh no!

Let's debug this :). How far are you through the tutorial? I'm asking because in the beginning, we're still loading users from our "hardcoded" list in security.yml. Later, we load from the database. But in more recent versions of Symfony, we've *changed* what the out-of-box security.yml file looks like - and it *no* longer includes these "hardcoded" users by default. That *might* be the cause of the problem. Here's what the entire security.yml file originally looked like in this tutorial at the end of the next chapter (so, after we finish the login form stuff): https://gist.github.com/wea...

Or, it could be something entirely different - let me know what your setup looks like :). The good news is that this error tells us that the User couldn't be found - so we can rule out there being some problem with checking the user's password.

Cheers!

Hey Dan,

You should use "print something - {{ }}" syntax instead of "do something {% %}", here's a right solution:

{{ render(controller('AppBundle:Security:login')) }}

This will fix "Unexpected render tag..." error.

Use is defined test or default Twig filter in template:

{% if error is defined %}
{# or #}
{% if error|default(false) %}

Btw, you could only render both forms on homepage, but process them on its separate pages, just use the correct action in your forms. If user leaves some validation errors - he'll end up on form login page/ registration page. But if user fills form correct - he will be processed and won't see login/registration pages at all.

Cheers!

It worked! Cheers!

Yes it is! But it's a simple deprecation :) - the constants were moved to a class called Security. So, the new way is:

use Symfony\Component\Security\Core\Security;

// ...
Security::AUTHENTICATION_ERROR

Btw - this is the tutorial for Symfony 2 - we have an updated Security tutorial for Symfony 3: http://knpuniversity.com/sc... - it has all the latest and greatest ways of doing things :).

Cheers!

Hey, Daniel!

Are you talking about checkCredentials() method which should be implemented from AbstractGuardAuthenticator? If so, then yes, you should return "true" to cause authentication success.

<blockquote>If getCredentials() returns a non-null value, then this method is called and its return value is passed here as the $credentials argument. Your job is to return an object that implements UserInterface. If you do, then checkCredentials() will be called. If you return null (or throw an AuthenticationException) authentication will fail.
</blockquote>

You can find explanation of other methods on <a href="http://symfony.com/doc/current/cookbook/security/guard-authentication.html#the-guard-authenticator-methods&quot;&gt;The Guard Authenticator Methods</a> page.

Cheers!

Hi there!

If you're building an API, then there's limited useful ness to using FOSUserBundle (you can use it still for your User document, but you won't use any of its other features). In this case, your error is just because you have a bad namespace (or something) with your authenticator. The namespace and services.yml look good to me. So, does this file live in the correct location? It should be "src/Arably/RestBundle/Security/FormLoginAuthenticator.php".

Btw, we do have a tutorial about API authentication - it might be helpful! http://knpuniversity.com/sc...

Cheers!

Thanks for you response. I finally implemented the check login method and generated the JWT in it.

Hey cristicitea ,

What do you mean in the first question? What type of the roles field should you use? or something different?

Actually, you should add a role for user before he will be logged in. The most common way is to set some role, like ROLE_USER when user is doing registration, i.e. when you're creating a new user in the DB. So when users are logging in - they _already_ have some role. Then you can easily check wether a logged in user has the required role with isGranted() method, i.e. $this->isGranted('ROLE_USER') in your controller (but only if you extends the Symfony\Bundle\FrameworkBundle\Controller\Controller class) or use @security.authorization_checker service otherwise.

Cheers!

so, do I literally add ROLE_USER in the roles field in the database? Also, will the security file catch that role in the`
access_control`
automatically?

for example, if i am logged in as an admin, will this code understand that I am logged in as admin?

 { path: ^/test, roles: ROLE_ADMIN }```

Hey cristicitea ,

Yes, you should store user roles in database, for example when you store user information during registration. And yes, Symfony app should understand, but try it to double check - sometimes you could miss something in config. Take a look at our course Symfony Security: Beautiful Authentication, Powerful Authorization - it has nice example about dynamic user roles at the end.

Cheers!

ok, I figure it out. the roles field in the db takes an array`
["ROLE_USER"]`
. And using an annotation works as well`
@Security("is_granted('ROLE_USER')")`

Yes, that's great! Actually, I use both access_control list and @Security annotation to be sure with proper security. Even more, you can double check if user has access with custom call of isGranted() method in actions. ;)

Cheers!

There's a use statement at the top of that file:

use Symfony\Component\Security\Core\Security;

I just forgot to "show" it in the code-block. I'll fix that now!

I also use the php bin/console debug:router command and I get the /login listed :/

Hey dash!

You already guessed my first debugging technique - bin/console debug:router. If you see /login listed, then you should not be getting this "No route found for GET /login" error. I mean, really, it's basically impossible - so something *very* strange is happening! I would click the web debug toolbar to go into the profiler. Then, go to the Routing tab. This will show you all of the routes that were searched. Do you see /login there?

Cheers!

Dude. My browser save /Login instead of /login. Dammit XD

Soooo, after a day of debugging...I looked at the other annotation routes in the Event Controller and I missed the @ infront of 'Route'. *facepalm*

Bah, bummer! But good debugging! And sorry for the late reply! I especially liked that you ran router:debug - that is always what I do first when something happens that I don't expect with routing.

Good luck! At least you won't make that mistake again :)

No worries on the delay. It actually gave me a better understanding of Routing (and especially annotations).

Keep up the good work, love all your videos.

Hey Marco!

What's the error? The SecurityContextInterface *is* deprecated, but it obviously still exists (unless you're using Symfony 3.0, then it's removed). Either way, use the Symfony\Component\Security\Core\Security class instead. We'll be releasing updated tutorials with all the new classes you should use soon :).

Cheers!