Warning: You are browsing the documentation for Symfony 3.2, which is no longer maintained.
Read the updated version of this page for Symfony 6.0 (the current stable version).
Sometimes it may be necessary to integrate Symfony into a legacy application where you do not initially have the level of control you require.
As stated elsewhere, Symfony Sessions are designed to replace the use of
session_*() functions and use of the
superglobal. Additionally, it is mandatory for Symfony to start the session.
However when there really are circumstances where this is not possible, you
can use a special storage bridge
which is designed to allow Symfony to work with a session started outside of
the Symfony HttpFoundation component. You are warned that things can interrupt
this use-case unless you are careful: for example the legacy application
A typical use of this might look like this:
1 2 3 4 5 6 7 8 9 10 11 12 13
use Symfony\Component\HttpFoundation\Session\Session; use Symfony\Component\HttpFoundation\Session\Storage\PhpBridgeSessionStorage; // legacy application configures session ini_set('session.save_handler', 'files'); ini_set('session.save_path', '/tmp'); session_start(); // Get Symfony to interface with this existing session $session = new Session(new PhpBridgeSessionStorage()); // symfony will now interface with the existing PHP session $session->start();
This will allow you to start using the Symfony Session API and allow migration of your application to Symfony sessions.
Symfony sessions store data like attributes in special 'Bags' which use a
key in the
$_SESSION superglobal. This means that a Symfony session
cannot access arbitrary keys in
$_SESSION that may be set by the legacy
application, although all the
$_SESSION contents will be saved when
the session is saved.