8000 session_start() ordering problem new to 2.1 · Issue #79 · FriendsOfSymfony/FOSFacebookBundle · GitHub
[go: up one dir, main page]

Skip to content
This repository was archived by the owner on Nov 9, 2017. It is now read-only.
This repository was archived by the owner on Nov 9, 2017. It is now read-only.
session_start() ordering problem new to 2.1 #79
@weaverryan

Description

@weaverryan

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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0