All about the User class

Video not working?

It looks like your browser may not support the H264 codec. If you're using Linux, try a different browser or try installing the gstreamer0.10-ffmpeg gstreamer0.10-plugins-good packages.

Thanks! This saves us from needing to use Flash or encode videos in multiple formats. And that let's us get back to making more videos :). But as always, please feel free to message us.

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!

  • 2019-08-27 Ozornick

    Sorry for my carelessness. Yes, the lesson says "save to doctrine."

  • 2019-08-26 Diego Aguiar

    Ohh interesting. I've never said no to "Store user data in the database" - I learnt something new today :)

    Cheers!

  • 2019-08-26 Ozornick

    brilliant! I would think about it for a long time. The lesson asked not to persist in doctrine.

  • 2019-08-26 weaverryan

    Hey Ozornick!

    Indeed, maker:user might create something in src/Entity OR in src/Security. The deciding point is this question:

    > Do you want to store user data in the database (via Doctrine)?

    If you answer yes to that, we create an entity in src/Entity. If you say not to that, we create a "plain old PHP object" in src/Security. It's made to work for both use-cases.

    Does that clarify things?

    Cheers!

  • 2019-08-23 Ozornick

    Ok, ok. https://ibb.co/3426x19 in Security cat

  • 2019-08-23 Diego Aguiar

    Hey Ozornick

    It's good to see you again :)
    About your question, I don't fully get your point. The command make:user does not generate anything on src/Security folder. I just tried it out on Sf4.3 and it creates/updates the same files as shown on the video. Could you clarify things a bit?

    Cheers!

  • 2019-08-23 Ozornick

    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?

  • 2019-08-13 Steve

    Thank you Vladimir. I'm actually importing the database from my local dev to the remote dev and the user table won't import as the remote DB is version 5.5.6 and doesn't like the field type JSON.

    I'm going to either refactor the roles to be an entity or get the DB version on the remote server upgraded.

    Thanks again

    Steve

  • 2019-08-12 Vladimir Sadicov

    Hi Steve

    You can try to set doctrine.dbal.server_version like:

    doctrine:
    dbal:
    server_version: 'mariadb-5.5.60'

    Cheers!

  • 2019-08-12 Steve

    I've hit an issue with type=json for the roles. This is not supported in MariaDB 5.5.60. Is there an easy solution, other than upgrading the DB version?

    Thanks

  • 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?