Users

User entity sketch

The User class is a normal entity with one extra job: it implements the framework user interface. That interface asks for an identifier, usually the email.

The identifier must be unique in the database, so logins never match two rows. Keep the class small: email, password hash, and roles.

class User implements UserInterface { #[ORM\Column(length: 180, unique: true)] private string $email = ""; public function getUserIdentifier(): string { return $this->email; } }

Password hashers

Passwords never land in the database as plain text. The hasher turns each password into a salted hash that checks but never decrypts.

Hash at registration and verify at login. Both calls take the user object first so future algorithms can migrate hashes silently.

$hash = $hasher->hashPassword($user, "secret123"); $isOk = $hasher->isPasswordValid($user, "secret123");

User provider note

A user provider reloads the visitor from storage on every request. The entity provider does this with one mapping: class plus login field.

The snippet below points the provider at the User class by email. Custom providers exist, but most projects never need them.

security: providers: app_user_provider: entity: class: App/Entity/User property: email

Store roles

Roles live on the user as a plain string array in one column. Every account keeps at least the base user role.

The getter returns the stored list. Admin screens add more roles to the same array without new tables.

public function getRoles(): array { return ["ROLE_USER"]; }

Next: Login form

Article author: Arthur Isaev