All about the User class
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!
Again I guys) In Symfony 4.3.3 make:user creates the essence of src/Security/User.php. Next, you say edit User make:entity and oops ..! A NEW class is created in src/Entity/User.php Can make a note or edit the code under 4.3.3?