Buy
Buy

Now matter how your users will login, the first step to creating an authentication system is to create a User class. And we just did that with the handy make:user command.

Go check out that class: src/Entity/User.php:

... lines 1 - 2
namespace App\Entity;
use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Security\Core\User\UserInterface;
/**
* @ORM\Entity(repositoryClass="App\Repository\UserRepository")
*/
class User implements UserInterface
{
/**
* @ORM\Id()
* @ORM\GeneratedValue()
* @ORM\Column(type="integer")
*/
private $id;
/**
* @ORM\Column(type="string", length=180, unique=true)
*/
private $email;
/**
* @ORM\Column(type="json")
*/
private $roles = [];
public function getId(): ?int
{
return $this->id;
}
public function getEmail(): ?string
{
return $this->email;
}
public function setEmail(string $email): self
{
$this->email = $email;
return $this;
}
/**
* A visual identifier that represents this user.
*
* @see UserInterface
*/
public function getUsername(): string
{
return (string) $this->email;
}
/**
* @see UserInterface
*/
public function getRoles(): array
{
$roles = $this->roles;
// guarantee every user at least has ROLE_USER
$roles[] = 'ROLE_USER';
return array_unique($roles);
}
public function setRoles(array $roles): self
{
$this->roles = $roles;
return $this;
}
/**
* @see UserInterface
*/
public function getPassword()
{
// not needed for apps that do not check user passwords
}
/**
* @see UserInterface
*/
public function getSalt()
{
// not needed for apps that do not check user passwords
}
/**
* @see UserInterface
*/
public function eraseCredentials()
{
// If you store any temporary, sensitive data on the user, clear it here
// $this->plainPassword = null;
}
}

Two important things. First, because we chose "yes" to storing user info in the database, the command created an entity class with the normal annotations and id property. It also added an email property, a roles property - that we'll talk about later - and the normal getter and setter methods. Yep, this User class is just a normal, boring entity class.

Now look back at the top of the class. Ah, it implements a UserInterface:

... lines 1 - 5
use Symfony\Component\Security\Core\User\UserInterface;
... lines 7 - 10
class User implements UserInterface
{
... lines 13 - 99
}

This is the second important thing make:user did. Our User class can look however we want. The only rule is that it must implement this interface... which is actually pretty simple. It just means that you need a few extra methods. The first is getUsername()... which is a bad name... because your users do not need to have a username. This method should just return a visual identifier for the user. In our case: email:

... lines 1 - 10
class User implements UserInterface
{
... lines 13 - 46
/**
* A visual identifier that represents this user.
*
* @see UserInterface
*/
public function getUsername(): string
{
return (string) $this->email;
}
... lines 56 - 99
}

And actually, this method is only used by Symfony to display who is currently logged in on the web debug toolbar. It's not important.

Next is getRoles():

... lines 1 - 10
class User implements UserInterface
{
... lines 13 - 56
/**
* @see UserInterface
*/
public function getRoles(): array
{
$roles = $this->roles;
// guarantee every user at least has ROLE_USER
$roles[] = 'ROLE_USER';
return array_unique($roles);
}
... lines 68 - 99
}

This is related to user permissions, and we'll talk about it later.

The last 3 are getPassword(), getSalt() and eraseCredentials(). And all 3 of these are only needed if your app is responsible for storing and checking user passwords. Because our app will not check user passwords - well, not yet - these can safely be blank:

... lines 1 - 10
class User implements UserInterface
{
... lines 13 - 75
/**
* @see UserInterface
*/
public function getPassword()
{
// not needed for apps that do not check user passwords
}
/**
* @see UserInterface
*/
public function getSalt()
{
// not needed for apps that do not check user passwords
}
/**
* @see UserInterface
*/
public function eraseCredentials()
{
// If you store any temporary, sensitive data on the user, clear it here
// $this->plainPassword = null;
}
}

So, for us: we basically have a normal entity class that also has a getUsername() method and a getRoles() method. It's really, pretty boring.

The other file that was modified was config/packages/security.yaml. Go back to your terminal and run:

git diff

to see what changed. Ah, it updated this providers key:

security:
# https://symfony.com/doc/current/security.html#where-do-users-come-from-user-providers
providers:
# used to reload user from session & other features (e.g. switch_user)
app_user_provider:
entity:
class: App\Entity\User
property: email
... lines 9 - 29

This is called a "user provider". Each User class - and you'll almost definitely only need one User class - needs a corresponding "user provider". And actually, it's not that important. I'll tell you what it does later.

But before we get there, forget about security and remember that our User class is a Doctrine entity. Let's add another field to it, generate a migration & add some dummy users to the database. Then, to authentication!

Leave a comment!

  • 2018-10-19 weaverryan

    Hey Ahmad Mayahi!

    Hmm, great question! This comes from MakerBundle... but I implemented this code :). And I don't exactly remember why I decided to do it this way. I mean, I "kind of" know. I decided to add the `:string` return type... which is just nice to have. Because of that, I needed to guarantee that the method returns a string. Because it's possible for email to be null (not in the database, but before it's saved, it's possible), I case it to a string to avoid a type error.

    I hope that clarifies! It's not too important of a detail :).

    Cheers!

  • 2018-10-18 Ahmad Mayahi

    Why do you cast email to string in getUsername() method?