[HttpFoundation][Sessions] NativeFileSession won't override the php.ini settings anymore #5267
Conversation
No, it is as the name says - native file session handler :-)
As I said before if you want to leave the save handlers as specified in php.ini (which is a mistake imo), then simply pass As a matter of principal, an application's configuration be explicit and not make assumptions about the environment it's deployed in. You might have an exception for this, but as a general rule, the application should behave the same way on server 1 or server 2 because it makes the application robust and saves some poor admin time scratching their head as to why server 1 works, and server 2's deployment doesn't.
This is why we had the
This is already configurable, the default folder is sensible for most purposes. Especially when testing or re-deploying clearing out sessions may make very good sense. |
|
This PR breaks the intended behaviour - there is no way to set to files if the environment was set to something other than files. The purpose of this class is to set the save handler to files. |
|
@Drak Thanks for feedback. I've got the first part but either I'm too asleep right now, or passing: handler_id: null doesn't help at all. All I get is a big error. You can check it out at: https://github.com/dlsniper/symfony-standard maybe you can spot something that I don't understand/I'm doing wrong. In regards to the whole As for changing the folder path, I think I've seen at least half a dozen of people complaining about the problem that they've deleted the cache folder and they've lost the sessions in process. Maybe a manual warning might be enough but lets face it, if they didn't knew where the sessions are stored what makes you think that they'll notice that? Even so, |
|
@Drak what about a cookbook entry detailing the setup to use in order to use the settings from php.ini ? |
|
@Drak if I change this in order to add an option to allow the user to ignore_ini_settings then would this be ok for the scope of the PR? Thanks. |
|
@dlsniper - you are missing the point. Doing so would just be a hack. The right way to do this is to allow the configuration in FrameworkBundle to accept null like this: For those not using just the component, they pass null in the constructor (which means just not completing the second arg). |
|
This PR can be closed for #5290 which achieves the requested end result but in a non-disruptive manner. |
Commits ------- 8e11aaa [FrameworkBundle] Allow to set null for the handler in NativeSessionStorage Discussion ---------- [FrameworkBundle] Allow to set null for the handler in NativeSessionStorage Bug fix: no Feature addition: yes (ok for RC) Backwards compatibility break: yes Symfony2 tests pass: yes Fixes the following tickets: 5267 Todo: ~ License of the code: MIT Documentation PR: ~ Refs #5267 Adds the following configuration ``` session: handler_id: ~ ``` Which allows the configuration of the session not to use any save handler and therefor just use whatever save_handler is set in `php.ini` --------------------------------------------------------------------------- by dlsniper at 2012-08-17T17:24:37Z :+1:
This is a redo of #5266 as I had to delete my repository for some other reasons.
Bug fix: yes - but in the 2.1 branch
Feature addition: no
Backwards compatibility break: not sure
Symfony2 tests pass:
Fixes the following tickets: ~
Todo: ~
License of the code: MIT
Documentation PR: ~
Today I've noticed that the sessions are stored in files even if the configuration of the PHP server was to use the memcached driver to do so.
After a bit of digging I've noticed that the native storage solution Symfony2.1 comes with will override the server settings in the PHP.ini which is very bad as this is not the expected default behavior.
I think this should be solved before releasing 2.1 as the changes for the session subsystem are already major.
One other thing to add to this would be to force the sessions to be stored in files regardless of the settings in php.ini but for that I think we need to use a configuration option. If you think that it would be better to solve the problem that way then I'll gladly do it.
cc @fabpot @Drak