Symfony 5 Security
Symfony 5 Security: encoders, providers, firewalls , access_control, role_hierarchy, Annotations in Controllers & Templates: @IsGranted(“ROLE_ADMIN”), Special Attribute: IS_AUTHENTICATED_FULLY, User Object
Following are key points related to Symfony 5 Security System summarized from the Symfony documentation.
Encoders
This option defines the algorithm used to encode the password of the users, this is in fact, “password hashing”.
Providers
For users to be authenticated, somewhere we must have a list of known users. This option defines how the application known users are loaded (from a database, a configuration file, etc.). Users are provided from app/config/security.yml (in_memory), or from database entities (user records in our database).
Firewalls
A “firewall” is your authentication system: the configuration below it defines how your users will be able to authenticate (e.g. login form, API token, etc). Only one firewall is active on each request: Symfony uses the pattern key to find the first match. Two firewalls are setup by default (dev: & main:). Each firewall must define a provider. No pattern key means it matches all URLs
Access_control
Role based access control for large sections of the site. It’s used to trigger the user authentication when they are trying to access certain areas. Users trying to access a URI must have specific roles. This option is explained in detail in How Does the Security access control Work?.
Role_hierarchy
Instead of associating many roles to users, this option allows you to define role inheritance rules by creating a role hierarchy, as explained in Hierarchical Roles.
SECURITY USING ANNOTATIONS IN CONTROLLERS & TEMPLATES
@IsGranted(“ROLE_ADMIN”)
If the user is logged in, but does not have the ROLE_ADMIN role, they'll be shown the 403 access denied page (which you can customize).
Special Attribute: IS_AUTHENTICATED_FULLY
If you only want to check if a user is logged in (you don’t care about roles), you have two options. First, if you’ve given every user ROLE_USER, you can just check for that role. Otherwise, you can use a special "attribute" in place of a role: IS_AUTHENTICATED_FULLY anywhere roles are used: like access_control or in Twig.
Get Faisal Mahmood’s stories in your inbox
Join Medium for free to get updates from this writer.
IS_AUTHENTICATED_FULLY isn’t a role, but it kind of acts like one, and every user that has logged in will have this. Actually, there are 3 special attributes like this:
1- IS_AUTHENTICATED_REMEMBERED: All logged in users have this, even if they are logged in because of a “remember me cookie”. Even if you don’t use the remember me functionality, you can use this to check if the user is logged in.
2- IS_AUTHENTICATED_FULLY: This is similar to IS_AUTHENTICATED_REMEMBERED, but stronger. Users who are logged in only because of a “remember me cookie” will have IS_AUTHENTICATED_REMEMBERED but will not have IS_AUTHENTICATED_FULLY.
3- IS_AUTHENTICATED_ANONYMOUSLY: All users (even anonymous ones) have this — this is useful when whitelisting URLs to guarantee access — some details are in How Does the Security access_control Work?.
USER OBJECT
After authentication, the User object of the current user can be accessed via the getUser() shortcut.
….. to be updated shortly
