This is mostly for myself as a reminder, as the info is scattered to hell wont have it, because that is the dysfunctional symfony way. The most frustrating part of Symfony is Authentication because the information is scattered all over between articles, symfonycasts etc. just all over, like you couldn’t scatter it more all over, all, all over like a unicorn farting out rainbow sprinkles.You won’t find shittier documentation on any subject anywhere on the internet.
There are two versions of authentication an old one and a new one. The old one uses Authentication providers the new one users just Authetincators. No one but the authors of Symfony know WTF the difference is though.
Note : to add confusion Symfony refers to what you usually call Sessions as Tokens FFS.
First off a list of files involved in the login process :
The login form obviously app/templates/security/login.html.twig
A security controller app/src/Controller/SecurityController.php
A user Provider aka the User entity class app/src/Entity/User.php
An Authenticator app/src/Security/LoginFormAuthenticator.php
When a user requests /login Symfony first calls LoginFormAuthenticator.php to check to see if the user is logged in/authenticated so the work is not done in the controller like most other actions. To change, add, remove anything from the authentication process you make changes in the LoginFormAuthenticator.php methods.
This authenticator is listed in the app/config/packages/security.yaml file under firewalls:main:guard:athenticators as
Every time a request is made the firewall will use the authenticator listed to try to authenticate the user. If authentication fails Symfony secretly behind the scenes tries other ways to authenticate the user as you can see in the image below.
As you can see in the image above Symfony will try your guard you listed in the configuration file, but it also tries it’s own secret list of default authenticators.
For information about the login form see this article in the scatterdocs. A little more info about the login form and process from the Symfony Spaghetti docs.
Plain session docs – This is the symfony documentation page about Sessions alone. This link shows the basic configuration and use of Sessions in Symfony. This also mentions not starting a session for Anonymous users and has links to other info about sessions.
Configuring Sessions and Save handlers – Symfony documentation link. This covers more about how to configure sessions and their Save Handlers. This is some of the better information about Sessions and how they work in Symfony. It covers the save handlers and more of the configuration information.
Session proxy examples – Symfony Documentation link. This covers how to create your own session handler. It also discusses how to encrypt session data with an example.
Framework configuration – Symfony documentation link. This covers many of the options for the security component of Symfony.
Session Management – Symfony documentation link. Explains how sessions are managed in symfony. Gives a good overview and important information about how symfony functions. It covers the functions symfony uses to replace PHP session functions and how to use them. This also covers the ways to work with sessions in Symfony. Oddly this covers Flash messages too.
One thing you will want to do is view your current security settings to do so you use this command. php bin/console debug:config security
Old symfony cookbook security entry – This is an ancient link to nearly the very beginning of symfony. This explains the mechanics of the Symfony security system if you are like me and just want to know how the hell this functions so you can feel confident in the system and be able to diagnose and fix issues.
More on Security – this is another ancient link like above, it explains the system.
Symfony cast covering firewall and authentication and how it works. This has lots of info that should be directly in the documentation.
Security configuration reference -> not complete listing of some of the values you can set. If you run the debug:config command above you will see more values you can set, but good luck figuring out what they do.
How to restrict firewalls to a request -> symfony docs. This talks about using multiple firewalls and how the Symfony firewall system works like a waterfall trying one firewall after another until it finds one that works or uses the last firewall listed. This also explains some of the options to the firewall. This basically shows how to use multiple firewalls.
Symfony cast about security – this covers the entire system. Some things have changed in version 5 but this is mostly correct and serves as a starting point.
Security user providers – Part of the Firewall/Authentication/Authorization system is something called security providers. User providers check the users identity from a session cookie to verify the user. This part of the documentation talks about how the firewall uses the User providers to authenticate the user after they have logged in.
Installing and configuring Redis for Symfony takes quite a few steps. So many I’d never remember them all. This article is for myself at a later date as well as anyone else who finds it useful. I’ll be updating this article as I learn more.
This article covers installing and configuring Redis for use for both Session storage and Application cache.
If you are using docker once you have started a Redis instance test it by trying to use the cli like so
You should see something similar to this.
This means redis is running on 127.0.0.1 (localhost) on port 6379 which is the default port.
With redis-cli running you can further test with the following.
//set a key and value
set someKey "some value for the key"
//get the value for the key
//view a list of all keys in redis storage
In production you need to install Redis or have access to a server running Redis, I’ll cover that in another article.
Install phpredis extension
You will need to install phpredis php extension and configure it. Before you can even do that though, you will need to install another php module php-dev I am using php 7.4 and Ubuntu so to install that I do this.
apt-get install php7.4-dev
This is needed because phpredis use phpize and phpize is included in php-dev.
If you are using another version of php you can search apt repository for this package like this:
apt search php-dev
or for version specific like this apt search phpver-dev apt search php7.4-dev
This is just the extension for the client to interact with your Redis server wherever it is, either local or remote.
Now you must configure PHP to use this extension.
You could add the needed config values to the php.ini config, but the problem is there are two. Yeah one for the cli and one for fpm. I have an easier solution. Create one file and symlink for both cli and fpm.
You will need both configured. As I found out if you configure only fpm your app will work, but when you go to composer install/update/require etc. you will get a cli error about missing such and blah Redis extension blah blah.
If you are running PHP 7.4 on Linux you will want to create a file in the following /etc/php/7.4/mods-available directory named phpredis.ini with the following
session.save_handler = redis
session.save_path = "tcp://localhost:6379?timeout=3&read_timeout=3"
The way this works is php after it reads the php.ini reads in all of the configuration files ( those with .ini extension) from the conf.d directory for either cli if you are using the command line or from fpm for your app. This makes configuring anything you need for php easier than having to open the giant php.ini file, plus you don’t have to worry about ruining one, which I have done easily. Here is a link to the php docs on configuring and .ini files
Now you must restart php fpm for your app to work. On Ubuntu you can do this.
service php7.4-fpm restart
Configure Symfony for Redis Sessions
Now you must configure some things in Symfony. Part of the following can be found in the docs about caching in a Redis Database here.
From the docs you can see you need set these values inside services.yaml which is in the config directory of your app.
# you can also use \RedisArray, \RedisCluster or \Predis\Client classes
# uncomment the following if your Redis server requires a password
# - auth:
# - '%env(REDIS_PASSWORD)%'
The values for REDIS_HOST, REDIS_PORT and REDIS_PASSWORD should be defined in environmental variables on your system or in .env or in the secrets vault. For testing .env.test.local works.
Now there is still a little more configuring as the docs show in the link above. You need to configure the framework to use Redis for session storage. Open framework.yaml located in config/packages/ and change the handler_id and comment out the save_path file location info like so.
You also need to configure the cache now in cache.yaml if you want to use Redis as a cache for your app. You could configure everything in framework.yaml but it becomes a mess if you do that. Symfony reads all the files recursively located in the config directory, just make sure your yaml structure is correct.
If you open /yourapp/config/packages/cache.yaml you should see something similar already there.
# Unique name of your app: used to compute stable namespaces for cache keys.
# The "app" cache stores to the filesystem by default.
# The data in this cache should persist between deploys.
# Other options include:
# APCu (not recommended with heavy random-write workloads as memory fragmentation can cause perf issues)
# Namespaced pools use the above "app" backend by default
Un-comment the lines shown under Redis section. You will notice a special syntax I am using. I kept messing around until it worked. You might not need to configure the default_redis_provider I need to do more research on that because it seems like that should be covered from the configs above, seems redundant.
Often you may need to know whether a user is logged in or not inside a template to show or not show something. For example you might want to show links to login or register if a user is not logged in but show a link to logout if the user is logged in.
To do this you use is_granted() within a template with one of the following.
Using ROLE_SUPER_ADMIN_1 which is something I made up for my own app to check what type of admin the user is. I don’t really like the IS_AUTHENTICATED_* methods, read more about them in the link below if you want.