Managing User Sessions in Symfony 6: A Beginner's Guide PT2

This post is the second part of the article about how sessions work and how to implement them in your PHP Symfony 6 framework application.

If you haven’t read that already I’d advise you to get the basics and return to this one.

Otherwise, have a great read.

Where were we?

In the last article, we described what sessions are and how to use them.

Pretty basics stuff! 

In this one, we go over some details like how to use flash messages, the security aspect, and how to debug issues.

Flash messages in Symfony 6

Flash messages are a way to show a message to the user after a specific action has been performed, such as submitting a form or deleting a record. 

An example can be when you buy something and see a pop-up showing up on the screen.

Implement them into your application is pretty straightforward, here are the basic steps to use flash messages in Symfony 6:

1. Set a flash message using the setFlash() method provided by the Session class. Like this: $this->addFlash('success', 'Your record has been deleted successfully!');

2. You can display the flash message in your Twig template using the flash() function. For example, you can display the success message with this syntax: {{ flash('success') }}

3. Style the flash message: You can customize the style of the flash message by adding CSS classes to the message container. If you are using a CSS framework you can add the ‘alert alert-success’ classes to the success message container as follow: {{ flash('success', {'classes': 'alert alert-success'}) }}

You can check what these look like using Bootstrap.

How to configure Flash messages in Symfony

To configure flash messages in Symfony 6, you can modify the default settings in your application’s configuration file. 

In the framework.yaml file in your application’s config directory, you can modify the `session` settings to configure how flash messages are stored and displayed. 

For instance, you can set the flashbag_name parameter to change the name of the flash message session variable. 

You can also set the auto_flush parameter to false to prevent the flash messages from being automatically removed after they are displayed.

Here’s an example of how you can modify the Flash messages settings:

framework:
    session:
        flashbag_name: my_flash_messages
        auto_start: true
        cookie_secure: auto

In this example, the flashbag_name parameter has been set to my_flash_messages, which means that flash messages will be stored in a session variable called my_flash_messages. 

The auto_start parameter has been set to `true` to automatically start the session, and the cookie_secure parameter has been set to `auto` to determine if cookies should be sent over secure connections.

As I mentioned in the section above note that you can also configure the style of the flash messages by modifying the Twig templates that display them. 

You can override the default Twig templates in your application’s `templates` directory.

Flash messages are only stored in the session for one request, and they are automatically removed after they have been displayed.

There are several types of flash messages that you can use to communicate different types of messages to the user. 

These types are represented by keys that you can pass to the setFlash() method. 

Here are the different types of flash messages in Symfony 6:

success: This type of flash message is used to communicate that an action has been completed.

error: This type of flash message is used to communicate that an error occurred while acting.

warning: This type of flash message is used to communicate a warning or caution to the user.

info: This type of flash message is used to communicate general information to the user.

You can also define your custom flash message types by using any string as the key for the setFlash() method. 

You can define a custom type like this: 
 

$this->addFlash(‘custom’, ‘This is a custom flash message!’);

Image from Unsplash

Session security in Symfony 6

The next topic on the list is security.

Symfony 6 provides session security in several ways. 

One of the most notable ways is through the use of session fixation protection, which helps to prevent session hijacking attacks. 

When a user logs into an application, Symfony generates a new session ID for them. 

This ensures that even if an attacker can obtain the original session ID, it will be rendered useless as the user’s current session will have a different ID.

Another way Symfony 6 provides session security is through the use of cookie options. 

Symfony allows developers to configure cookie options such as the secure flag, HttpOnly flag, and SameSite attribute to help prevent various types of attacks. 

The secure flag ensures that cookies are only transmitted over HTTPS, while the HttpOnly flag ensures that cookies cannot be accessed by client-side scripts. 

The SameSite attribute specifies whether cookies can be sent in cross-site requests, helping to prevent cross-site request forgery attacks.

In addition to these measures, Symfony also provides other security features such as cross-site scripting protection and a content security policy. 

These features help to prevent common web application attacks and ensure that sessions remain secure for users.

One way Symfony 6 protects against session hijacking is by regenerating session IDs after certain actions or time intervals. 

This makes it more difficult for an attacker to guess or use a stolen session ID to access a user’s session.

The session ID can be regenerated after a user logs in, changes their password, or after a certain amount of time has passed since the last regeneration. 

This can be configured in the security settings of the application.

Symfony 6 also supports using secure session cookies, which can only be sent over HTTPS connections. 

This helps to prevent session hijacking through sniffing attacks, where an attacker intercepts unencrypted network traffic to steal session cookies.

Lastly, Symfony 6 provides built-in protection against brute-force attacks on session IDs. 

If an attacker repeatedly tries to guess a valid session ID, Symfony 6 can block the attacker’s IP address or temporarily disable the user’s account to prevent further guessing attempts.

Symfony 6 handles expired sessions by automatically garbage collecting them. 

What is garbage collection?

It is a process of removing stale sessions that are no longer needed. 

Symfony uses a garbage collection mechanism that removes expired sessions from the session storage. 

This ensures that the session data is always fresh and up-to-date. 

The garbage collection process can be configured in Symfony 6 using the gc_maxlifetime parameter. 

This parameter defines the maximum lifetime of a session before it is considered expired and eligible for garbage collection. 

By default, Symfony uses an gc_probability of 1 and a gc_divisor of 100, which means that the garbage collector will run on every request with a 1% probability. 

This ensures that expired sessions are removed promptly and do not accumulate in the session storage, which can cause performance issues.

Session debugging in Symfony 6

Debugging sessions in Symfony 6 can be a crucial step in resolving issues related to sessions. 

But there are several steps you can take to debug a session.

Here is how:

First thing you need to enable debug mode.

You can do this by setting the APP_ENV variable to “dev” in your .env file or by running the following command in the terminal:

php bin/console debug:config framework

Secondly, you need to enable the session debugging.

To enable session debugging, add the following configuration to your config/services.yaml file:

services:
 session.listener.debug:
 class: Symfony\Component\HttpFoundation\Session\EventListener\DebugSessionListener
 tags:
 — { name: kernel.event_subscriber }

Then dump the session data.

To do so you can use the following command:

php bin/console debug:container session

This will show you the session data in your terminal.

Symfony 6 has several events that are triggered during a session lifecycle. You can use the following command to debug these events:

php bin/console debug:event-dispatcher kernel.request

This will show you all the listeners and subscribers that are listening to the kernel.request event.

This is triggered at the beginning of every request.

By following these steps, you can debug sessions in Symfony 6 and identify any issues related to session management.

Sessions can sometimes encounter problems that prevent them from functioning as expected, such as session data not being saved, sessions being lost or expired too soon, or sessions being hijacked by attackers.

To troubleshoot these problems, one may need to examine the Symfony 6 configuration for session handling, review the code that interacts with sessions, and use tools like logging and debugging to trace the flow of session data. 

Common solutions may involve adjusting session configuration settings, modifying code that manipulates session data, or implementing additional security measures to prevent session hijacking.

By effectively troubleshooting session problems, developers can ensure that their Symfony 6 applications can properly manage session data and maintain the security and integrity of user sessions.

Now that you are a master of using flash messages and debugging every session let’s have a look at what are the best practices when using them.

Best practices for using sessions in Symfony 6

The first thing I’d suggest is to use HTTPS.

Sessions contain sensitive data such as user IDs and passwords, so it’s important to encrypt them with HTTPS. 

Without HTTPS, session data can be intercepted and stolen by attackers.

I’d recommend setting an expiration time for your sessions to limit the amount of time-sensitive data stored in the session. 

This can help prevent session hijacking and other security issues.

Make sure to use a strong session ID to prevent attackers from guessing or brute-forcing it. 

Symfony provides secure session ID generation by default, but you can also customize it if needed.

Regenerating session IDs periodically can help prevent session fixation attacks, where an attacker tries to fixate a user’s session ID and then hijack the session. 

Symfony provides an easy way to regenerate session IDs using the SessionInterface class.

Symfony provides the SessionBagInterface to store data in the session using a structured format. 

This can help prevent conflicts between different components and reduce the risk of overwriting data.

Try your best to avoid storing sensitive data such as passwords or credit card numbers in the session. 

What you can do is secure storage solutions such as encrypted databases or secure file storage.

The most important for me remains testing.

Testing session functionality is important to ensure that it works as expected and that there are no security vulnerabilities. 

Use PHPUnit and Symfony’s built-in testing tools to test session functionality.

I have created a whole series on how to use PHPUnit. 

By following these best practices, you can help ensure the security and reliability of your Symfony 6 application’s session functionality.

Conclusion

In this 2-part article, you have learned a lot about how and why it is important to properly manage sessions in your Symfony 6 application.

My advice would be to read the full article a few times, save it and come back to it now and then so you can remind yourself about the best practices and refactor the code in your applications.

If you have read so far please subscribe to the newsletter so you will be the first to be notified when a new blog post about PHP and Symfony is published.