According to the standard 2.4 documentation, the security.yml config file allows for the following configuration option:
session_fixation_strategy: none | migrate | invalidate
source: http://symfony.com/doc/current/reference/configuration/security.html
However, I fail to find any details in the official documentation (or elsewhere) on what this option actually does, or how it works in practice.
So, if I set this option to either "migrate" or "invalidate", how will this affect session handling in my system? For example, if I set it to "invalidate", would this mean that a context-local session is invalidated when the user navigates to a different security context?
In short:
- NONE: the session is not changed
- MIGRATE: the session id is updated, attributes are kept
- INVALIDATE: the session id is updated, attributes are lost
In detail:
None strategy:
Nothing is (supposed to be) done in the default session implementation, thus the session is maintained from one context to the other.
Migrate strategy:
"Migrates the current session to a new session id while maintaining all session attributes."
(The session storage should regenerate the current session.)
"Regenerates id that represents this storage.
This method must invoke session_regenerate_id($destroy) unless this interface is used for a storage object designed for unit or functional testing where a real PHP session would interfere with testing. Note regenerate+destroy should not clear the session data in memory only delete the session data from persistent storage."
Thus the session is retained from one context to the other.
Invalidate strategy:
"Clears all session attributes and flashes and regenerates the session and deletes the old session from persistence."
Thus the session is regenerated from one context to the other.
It was not revealed by your question what kind of session data you are trying to fetch.
But in any case, no separate session is generated for different security contexts:
http://symfony.com/doc/current/reference/configuration/security.html#firewall-context
Security (authentication) related data is stored under a separate key (based on the firewall name). So for example if you have a firewall with a name 'main', the authentication token will be stored under '_security_main', if you have a firewall (a separate context) with a name 'foo', the user and related token data will be stored under '_security_foo', etc.
So besides ->getToken ->getUser (etc.) the rest of the session variables will be available in different contexts provided you use the 'none' or the 'migrate' session strategies.
Take a look at the session interface for details (quotes are from these files)
vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Session/SessionInterface.php
And the default implementation:
vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Session/Session.php
