-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Session] hasSession() function fails to detect if the session is started or not before returning #4529
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@Drak could you take a look at it ? |
@stof ok. |
@Drak I'm working on a fix for it, it's not ready for a PR yet but I've seen something interesting. framework:
session:
auto_start: false and I try to do a $request->getSession()->set() or $request->getSession()->get() then the session doesn't start automatically. I know that auto_start should work just like the session.auto_start from PHP but in the case of a framework, maybe this should be a bit more smarter that the language itself and auto start a session when you do a get/set? that would help eliminate the auto_start need from the session config and also prevent the need to start the session manually. I'll publish a branch in my repository soon if you want to have a look at the patch so far and provide some input on it. Thanks. |
@dlsniper and Symfony 2.0 actually works the way you describe. So, this is a regression. |
Commits ------- 8dd2af7 Added Session Metadata info to the Request section of the WDT Discussion ---------- [WebProfilerBundle] Added Session Metadata info to the Request section of the WDT Bug fix: no Feature addition: yes Backwards compatibility break: no Symfony2 tests pass: [](http://travis-ci.org/dlsniper/symfony) Fixes the following tickets: #4181 Todo: ~ License of the code: MIT Documentation PR: ~ This PR adds some session metadata available into the WDT (Created, Last used, Lifetime specifically). If you'd like to see more info then let me know. --------------------------------------------------------------------------- by travisbot at 2012-05-26T21:11:56Z This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1443801) (merged 9b0b4383 into 9e95199). --------------------------------------------------------------------------- by travisbot at 2012-05-26T21:24:27Z This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1443856) (merged 31858319 into 9e95199). --------------------------------------------------------------------------- by drak at 2012-05-27T00:48:37Z Nice addition. --------------------------------------------------------------------------- by dlsniper at 2012-05-31T21:21:37Z @Drak While using this patch on a production application I've noticed that the `$request->hasSession()` section will fail to recognize that there's no session anymore in the app if I'm not using the auto-start feature. I'm using the latest master branch, updated today around 12:00 UTC. Clearly this is not the right place to discuss that there's a problem with ::hasSession() but I wanted to ask someone else for an opinion before creating the issue/fix for it. --------------------------------------------------------------------------- by stof at 2012-06-09T10:14:05Z @dlsniper create an ticket for it, and it will become the best place to discuss it :) --------------------------------------------------------------------------- by dlsniper at 2012-06-09T10:42:58Z Ok, but then can this be merged meanwhile? --------------------------------------------------------------------------- by stof at 2012-06-09T10:58:39Z @fabpot 👍 --------------------------------------------------------------------------- by dlsniper at 2012-06-09T17:36:24Z I've opened #4529 to address the issue seen in the comment.
@dlsniper - PHP session.auto_start and sf auto_start are completely different. I PHP |
|
Commits ------- f72ba0a Fixed detection of an active session Discussion ---------- [WIP][HttpFoundation][Session] Fixed detection of an active session Bug fix: yes Feature addition: no Backwards compatibility break: not sure Symfony2 tests pass: no Fixes the following tickets: #4529 Todo: Fix failing tests License of the code: MIT Documentation PR: ~ This fixes the problem when the session variable inside $request now has always data in it as it's now more powerful but this introduces the problem that the old way of detecting if a session is started or not doesn't work anymore. --------------------------------------------------------------------------- by travisbot at 2012-06-09T21:53:17Z This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1578839) (merged 9ae13e12 into 6266b72). --------------------------------------------------------------------------- by drak at 2012-06-10T01:57:59Z Sessions should be started implicitly. The SF auto_start config parameter controls the session listener to start the session. --------------------------------------------------------------------------- by dlsniper at 2012-06-11T06:46:02Z So this patch is correct then and I should continue the work on it? --------------------------------------------------------------------------- by drak at 2012-06-11T07:51:39Z @dlsniper - no it's not correct. The session should not be auto-started like this, @fabpot and I recently discussed it. --------------------------------------------------------------------------- by dlsniper at 2012-06-11T07:52:55Z @Drak, ok I'll remove the patch for auto_start then but the fix for start would still stand, right? --------------------------------------------------------------------------- by drak at 2012-06-12T18:40:35Z @dlsniper - I have no objection to the rest of the PR except for the autostart stuff. I've annotated for clarity :) --------------------------------------------------------------------------- by travisbot at 2012-06-12T19:51:12Z This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1604158) (merged 3499980e into 37550d2). --------------------------------------------------------------------------- by travisbot at 2012-06-12T19:52:00Z This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1604166) (merged dcc73071 into 37550d2). --------------------------------------------------------------------------- by dlsniper at 2012-06-12T19:56:51Z Seems Travis doesn't like the squashing of commits that I've did but the PR does pass the normal tests. @Drak is this good for merging now? Thanks :) --------------------------------------------------------------------------- by dlsniper at 2012-06-13T09:05:09Z @fabpot this can be merged safely, I've just applied the patch on my production application and the patch is ok, it's just travis failing. Thanks --------------------------------------------------------------------------- by travisbot at 2012-06-13T09:23:46Z This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1608735) (merged 1a6eabd2 into 37550d2). --------------------------------------------------------------------------- by travisbot at 2012-06-13T09:28:26Z This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1608758) (merged 4e3a93c8 into 37550d2). --------------------------------------------------------------------------- by dlsniper at 2012-06-13T09:29:28Z I've noticed that this is failing, I'll fix it later on today. --------------------------------------------------------------------------- by travisbot at 2012-06-13T15:14:01Z This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1611541) (merged 5504c4b7 into 37550d2). --------------------------------------------------------------------------- by drak at 2012-06-13T15:23:47Z It's possible that other tests are failing not related to this PR. Run the tests on the current master, and try rebasing your branch to the current master also. --------------------------------------------------------------------------- by dlsniper at 2012-06-13T15:44:22Z I've just reminded why this is failing on builds, I can't do them locally because of this: ``` Installing dev dependencies Your requirements could not be solved to an installable set of packages. Problems: - Problem caused by: - Installation request for doctrine/orm [>= 2.2.0.0, < 2.4.0.0-dev]: Satisfiable by [doctrine/orm-2.2.2, doctrine/orm-2.2.1, doctrine/orm-2.2.0, doctrine/orm-2.2.x-dev, doctrine/orm-2.3.x-dev]. ``` I'll try and install this somehow and see what's wrong with it. --------------------------------------------------------------------------- by mvrhov at 2012-06-13T18:08:58Z @dlsniper: as @stof said to me this should be resolved in latest versions of composer, but it seems that is not. The problem is that composer cannot figure out that you are on dev-master if you try to instal dev. dependencies on feature branch. Take a look at the .travis.yml file on how to do a proper dev vendors install. cc @Seldaek --------------------------------------------------------------------------- by dlsniper at 2012-06-13T23:08:53Z @mvrhov Thanks for pointing this out. @Drak I still got two tests not passing but I'm not sure how to fix them as adding $session->start() will either fail with the message that the session has already been started, the headers_sent() call which returns true. Any help with them will be greatly appreciated. Thanks! Here is what the HttpKernel tests are returning: ``` There were 2 failures: 1) Symfony\Component\HttpKernel\Tests\EventListener\LocaleListenerTest::testDefaultLocaleWithSession Failed asserting that two strings are equal. --- Expected +++ Actual @@ @@ -'es' +'fr' /var/www/symfony-orig/src/Symfony/Component/HttpKernel/Tests/EventListener/LocaleListenerTest.php:51 2) Symfony\Component\HttpKernel\Tests\EventListener\LocaleListenerTest::testLocaleFromRequestAttribute Expectation failed for method name is equal to <string:set> when invoked 1 time(s). Method was expected to be called 1 times, actually called 0 times. FAILURES! Tests: 263, Assertions: 1025, Failures: 2, Skipped: 10. ``` --------------------------------------------------------------------------- by travisbot at 2012-06-13T23:42:59Z This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1614883) (merged 1004b7c0 into c07e916). --------------------------------------------------------------------------- by travisbot at 2012-06-13T23:53:06Z This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1614897) (merged f72ba0a into c07e916). --------------------------------------------------------------------------- by dlsniper at 2012-06-16T20:14:41Z @stof / @vicb Hi, do either of you think that you can either point me out to the right direction for fixing this either ping someone else for home help as @Drak doesn't seem available for this and at the moment I'm pretty much clueless in what direction I should take this fix. Thanks! --------------------------------------------------------------------------- by dlsniper at 2012-06-19T14:16:29Z ping @fabpot Can you please provide some input on this one as I'm a bit stuck and seems noone else is available. --------------------------------------------------------------------------- by drak at 2012-06-20T10:24:43Z fyi - I'll be able to look again in a few days --------------------------------------------------------------------------- by fabpot at 2012-07-01T07:53:28Z I'm +1 to add the `isStarted()` method, but -1 for the change of `Request::hasSession`. --------------------------------------------------------------------------- by drak at 2012-07-01T09:06:15Z @fabpot, I agree. `hasSession()` should not be changed, it's semantically incorrect to make it return effectively "hasActiveSession".
Commits ------- 8dd2af7 Added Session Metadata info to the Request section of the WDT Discussion ---------- [WebProfilerBundle] Added Session Metadata info to the Request section of the WDT Bug fix: no Feature addition: yes Backwards compatibility break: no Symfony2 tests pass: [](http://travis-ci.org/dlsniper/symfony) Fixes the following tickets: symfony#4181 Todo: ~ License of the code: MIT Documentation PR: ~ This PR adds some session metadata available into the WDT (Created, Last used, Lifetime specifically). If you'd like to see more info then let me know. --------------------------------------------------------------------------- by travisbot at 2012-05-26T21:11:56Z This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1443801) (merged 9b0b4383 into 9e95199). --------------------------------------------------------------------------- by travisbot at 2012-05-26T21:24:27Z This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1443856) (merged 31858319 into 9e95199). --------------------------------------------------------------------------- by drak at 2012-05-27T00:48:37Z Nice addition. --------------------------------------------------------------------------- by dlsniper at 2012-05-31T21:21:37Z @Drak While using this patch on a production application I've noticed that the `$request->hasSession()` section will fail to recognize that there's no session anymore in the app if I'm not using the auto-start feature. I'm using the latest master branch, updated today around 12:00 UTC. Clearly this is not the right place to discuss that there's a problem with ::hasSession() but I wanted to ask someone else for an opinion before creating the issue/fix for it. --------------------------------------------------------------------------- by stof at 2012-06-09T10:14:05Z @dlsniper create an ticket for it, and it will become the best place to discuss it :) --------------------------------------------------------------------------- by dlsniper at 2012-06-09T10:42:58Z Ok, but then can this be merged meanwhile? --------------------------------------------------------------------------- by stof at 2012-06-09T10:58:39Z @fabpot 👍 --------------------------------------------------------------------------- by dlsniper at 2012-06-09T17:36:24Z I've opened symfony#4529 to address the issue seen in the comment.
Hi,
When using $request->hasSession() the function will always return true as the function checks for data existence in the session internal array but since the new model of sessions data is always there. This should be modified as it's returning false positives.
Thanks
The text was updated successfully, but these errors were encountered: