-
Notifications
You must be signed in to change notification settings - Fork 138
Description
The Symfony 2.1 branch makes the ProfilerListener a subscribe to the kernel.request
event. This means that the ProfilerListener is instantiated very early when all the kernel.request
listeners are being prepared (in ContainerAwareEventDispatcher::lazyLoad
). This means it's instantiated before any listeners on that event, including the listeners that start the session.
The problem is that the ProfilerListener's instantiation ultimately means that the FacebookSessionPersistence
class is instantiated, causing the session to be started before it's intended to be started.
This doesn't seem to cause an outward problem when developing (the session is started a little earler), but it does seem to break session storage in the test environment, because the following happens:
-
FacebookSessionPersistence
is instantiated before dispatchingkernel.request
. This starts the session, andsession_id()
is generated to a real value. -
TestSessionStorage
sees no cookie (since this is the first request) and sets the session_id to an empty string (https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/EventListener/TestSessionListener.php#L56) -
The normal
SessionListener
is called, which callsSession::start()
. This would normally generate the session_id() (since it's blank), but since the session is already started,start
does nothing and session_id stays blank. -
When session persistence kicks (https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/EventListener/TestSessionListener.php#L78), the session_id is blank. The session is saved, but under the "key" of a blank session_id().
-
On the next request when the session is loading, a brand new session_id is generated once again because the session_id is blank. Session storage does a lookup with this id, which of course brings nothing back. This looks like a new session and the cycle repeats.
The easiest solution would be to remove the session start from FacebookSessionPersistence, but I'm sure that has other consequences.
Ideas on the best way to solve this? Can we remove the session start from the above class?
Thanks!