session_start() runs in the current logic for Native Sessions here without checking first if the session has already started previous to the code running.
Fix for session_start() which doesn't check if the session has already started
This pull request passes (merged 09059f1 into 7bc6d6d).
You cannot assume that a non empty ID means the session has not started. The session ID can be set before starting a session.
What problem are you trying to solve? I can give some better advice if I understand what issue you are experiencing.
The patch resolves an issue where start_session() is called even if the session has already been started. This causes a PHP notice and can be seen on certain hosting environments.
can you show an example? Sessions are not supposed to be started outside of Symfony.
There is only a way to detect if a session has really started starting from PHP 5.4 using http://uk3.php.net/manual/en/function.session-status.php but I deliberately left this out because it would mean different behaviour depending on version. Sessions are not supposed to be started outside of Symfony's Session class as already documented.
This for example, is illegal under Symfony and the resulting PHP notice is correct. Starting the session outside of Symfony can result of other knock on effects (like a session starting with a different save handler than you expect) - therefor, the PHP notice is very welcome to show that something wrong has happened.
$session = new Symfony\Component\HttpFoundation\Session\Session();
If this is the expected behavior, that's ok. I have a project that sits ontop of WordPress, and a user has integrated their WordPress environment with their Symfony environment. WordPress loads first and then Symfony, which I'm guessing should then be flipped and this pull request can safely be closed as wontfix.
Having sf embedded inside another app is not that farfetched, so IMHO this should be supported.
I also agree that it should be supported.
This pull request fails (merged 09059f1 into 7bc6d6d).
If you are embedding Symfony into Wordpress, the you have to let Wordpress use it's own session management.
Yeah, I agree we should support this, but I guess in that case we should have a more explicit mechanism to delegate session starting.
@drak The point is that we need to allow this kind of integration (that's part of the interoperability we try to promote). So, even if the session was started by Wordpress, it should be usable within Symfony. We must allow the session to be shared between the two libraries.
@fabpot, are you willing to accept "fingers crossed" hacks in Symfony? It's going to mean people have to be deeply aware of the moving parts in order to avoid a collision - I would suggest if we look deeper here, there is probably another way of doing whatever the reporter is trying to do. For one, if using HttpFoundation, there should be no reason for the SF2 session code to be hit at all. If someone is running Symfony2 fullstack framework inside wordpress, it's seems possibly the wrong approach to solve the problem.
@sc0ttkclark can you provide some more details of what you are doing?
@drak: Don't get me wrong. I'm not suggesting to merge this PR. I'm just saying that it should be able to share the session between different PHP projects into one project. Note that I've not thought about that more than that, so I don't have all the implications in mind. That being said, in symfony1, it was definitely possible to do that kind of stuff.
don't we support the necessary config options for people to swap out the session handling? IIRC this is what we ended up doing for the Magento integration Bundle:
With a simple experiment I noticed that $_SESSION is null before session_start is called. Can we rely on this?
well to me the issue is that if Symfony2 is embedded into app X .. it means app X will execute code before and after. as a result if app X didnt start a session before Symfony2 was called, there is no guarantee that it will not want to start one afterwards. so imho session starting needs to be handled by only one app and the other simply has to hook into the other one.
@mevers47 - The point is, this particular concept here, while solving a problem one way, introduces other more serious problems elsewhere. I do not believe this particular approach is the way to solve the problem being experienced by @sc0ttkclark, but we really need to see his use-case first to know how best to approach it.
Thanks for the discussion, I'm glad this ended up being something you were interested in supporting.
If Symfony is pulled into the page on-top of WordPress (through a plugin or theme), there's a good chance that a session has already started. In certain circumstances, using session_start() can conflict, either with PHP notices, or very rare occurrences could actually change the existing session ID used previously, or reset the session data. I swear I've seen this happen with at least one user, but I didn't document my findings as well as I should have.. so feel free to ignore that.
If there can be some sort of method to check for an existing session, that would improve the ill effects caused by loading Symfony's session handling on-top of other projects.
@sc0ttkclark maybe it's a dumb idea but if the session is started maybe you could do a count($_SESSION) != 0 ?
@sc0ttkclark - I am not saying I support it, just that I am interested in finding a solution for you that is in the best interest of the integrity of the code.
Can you please tell me (off line if you like drak at zikula dot org) how you are integrating Sf2 into wordpress - until I see the implementation detail I can't help with any certainty.
That's where I can't assist, it wasn't I setting up the integration, it was someone else. I should have followed up with them and asked them to chime in on this thread. I don't know them personally, they were using my plugin for WordPress and I was offering support to them to help figure out what was going on when I found the issue.
I'm having what i think it is a similar problem:
What can we do to solve this? Is this normal behavior from symfony? I think this can cause problems in other External Authentication Providers with their own session functions.
@drak if you are still interested in finding a solution for this problem i can give you any details you need just ask. I'm very interested in solving this because we are investing a lot on symfony in my company but every single of our aplications uses saml for authentication.
I also need to start the session outside symfony and let it continue with it once the framework is booted, ignoring app level session config.
how about allowing this for PHP >= 5.4.0 for the moment? @drak's solution (session_status()) looks clean enough.
As apparently before PHP 5.4 tehre is no reliable way to check wether the session is started or not, I suggest instead to have a NativeProxySessionStorage, using the already existing NativeProxy handler, its code would be pretty straightforward, it'd never set any session ini setting, it'd never start any session, wouldn't use any metadatabag, because I don't think it makes sense to have 2 different starting points in that situation.
Basically here we only want to say : "the session management is handled outside symfony, if symfony needs the session, it should only populate the $_SESSION superGlobal with its stuff".
A drawback I see about this is whenever symfony needs to populate the session while it hasn't been started by the wrapping app, imo this case should not be considered / allowed, the wrapping app must start the session for all requests.
Can you guys merge this fix into release 2.2?
This is still affecting me on Symfony 2.3, I have a project where I need to manually start my own PHP session before Symfony's session handler kicks in. Would be great to get this merged in.
I just discovered the new PHP bridge session storage library in Symfony 2.3:
After switching the session storage system per those instructions, no longer having any session issues with my app.
So, no sure if any fix like this is actually still needed for Symfony 2.3... my use case is gone, not sure if others still have a need for it.
I've just submitted a PR with my last suggestion (#7305), I'd be happy to get some feedback.
I've also noticed something similar in the default form csrf provider, https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Extension/Csrf/CsrfProvider/DefaultCsrfProvider.php#L68 , which could probably be fixed for php 5.4 at least.
Can someone work on a patch from PHP 5.4 by using the new session_status() function?
@fabpot - I've been working on something over the last weekend - will submit soon.
@drak : did you see #7305? I'd love to get your feedback / remarks on this.
it has been addressed by #7571