FriendsOfSymfony/FOSFacebookBundle — Issue #79: session_start() ordering problem new to 2.1
Author: weaverryan
Created: 2011-11-24 06:10:33+00:00
State: open

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:

1) `FacebookSessionPersistence` is instantiated before dispatching `kernel.request`. This starts the session, and `session_id()` is generated to a real value.

2) `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)

3) The normal `SessionListener` is called, which calls `Session::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.

4) 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().

5) 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!