bolt: [Bug] Memcache Session Management broken

The session management in Bolt 3+ currently has a design flaw that breaks sessions in a couple of situations.

Bolt has it’s own session management that reads and writes directly to session storage and is not using the PHP native session storage like other applications (including silex and sf2 apps do). This leads to trouble when paired with the ability of Bolts SessionServiceProvider to parse and import PHPs session options. If you do this, Bolt essentially uses the same session storage as PHP and conflicts with it. See this scenario:

• PHP Session reads it’s data , currently containing “START”. This allways happens at “session_start”, probably during application boot.
• Bolt reads it’s session data, still containing “START”.
• Bolt writes “CHANGED” to it’s session (while not using PHPs session but writing to storage directly)
• PHP Writes “START” to it’s session at Script end automatically (It didnt get the change by bolt before) -> Session get’s overwritten!

This happens for all session handlers, that create the same storage when used by Bolt and by PHP. The filesystem handler is safe as it uses different paths and filenames. I don’t know about Redis, but memcache will use same host and storage key when used by Bolt and by the PHP session handler.

Suggested Solution

• Bad but working Disable the “import from ini” feature and provide an option to configure the memcache connection paths for Bolt inside it’s own config. Then you could remove the settings from PHPs session handler and the two would no longer conflict. This solution would however still try to reinvent then wheel, provide it’s own cookie mechanics and it has not lazy writes or script end handlers.
• Good Solution Use the session manager as it is supposed to be used and common to almost all Silex/Sf2 Apps. You create your own handlers, but access to session data still happens through PHPs native session functions. Then the custom handler is registered via session_set_save_handler. This has no drawbacks on security (validation still happens, just on session data and not on the mechanism to load them. There is no loss of features as the official mechanism is fully compatible with your solution and is actually the one preferred by SF2. The Handlers provided by SF2 and used by Bolt directly are actually intended to be sued like this.

Reproduction You can reproduce this by configuring the same session storage for PHP and for Bolt. This is easiest with a memcache handler (They will use the same connection and storage keys automaticlly, hence the bug). But you can probably also use the filesystem handler if you set the path and filename mechanisms so Bolt will use the same files as PHP would.

In my case, you can see a Session Error message on Login. You have to logout before that though, as the conflicting sessions from Bolt and PHP sometimes make it look like you are logged in.

You can also see that your memcache server gets strange requests not routed through Bolts session management.

Counter Test If you hard code the connection string to memcache inside the SessionServiceProvider and then remove the session settings from PHP, the conflicts vanish and sessions work fine again.