Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Losing session cookie while using WebTestCase for PHPUnit tests #3287

Closed
intelliapps opened this Issue Feb 6, 2012 · 5 comments

Comments

Projects
None yet
3 participants

I am building Symfony2 apps on OSX Lion using PHP 5.3.6, MySQL 5.5.19 and Apache 2.2.0.
I have PHPUnit 3.6.10 installed and develop using Eclipse Helios 2 with XDebug 2.1.2.

I set up some functional tests for the app I'm working on as a PHPUnit test extending the Symfony WebTestCase class.

I used the Client and Crawler classes to try and run through the app as I would from within a browser. However, I encountered a situation where the app behaves differently under test than it does in the browser. I found that this is because the session cookie is lost (reset?) at a particular point in the tests whereas this does not occur when running the app in the browser.

After investigating this (and comparing it to the other Symfony apps I've worked on) I have found that the loss of the session cookie occurs when requesting a sequence of urls as follows:

/AAAA/name
…followed by...
/cart OR /BBBB OR /BBBB/name

These happen to be transitions between different controllers. I have wondered whether WebTestCase is not intended to support tests across multiple controllers although it does seem necessary for functional tests? However, I believe the problem could still occur if routes on a single controller had urls which vary like this, although I haven't come across this scenario myself.

I found this by analysing the following calls within the Symfony BrowserKit:
from CookieJar::updateFromResponse() (called by Client::request())
to Cookie::fromString()

  1. IN: cookie = PHPSESSID=feb27189e1fe36592658c828f46a664d; expires=Sat, 04 Feb 2012 16:19:21 GMT, uri = http://calculator.dev/
  2. OUT: Cookie::path = /
  3. IN: cookie = PHPSESSID=feb27189e1fe36592658c828f46a664d; expires=Sat, 04 Feb 2012 16:20:32 GMT, uri = http://calculator.dev/plane
  4. OUT: Cookie::path = /
  5. IN: cookie = PHPSESSID=feb27189e1fe36592658c828f46a664d; expires=Sat, 04 Feb 2012 16:21:52 GMT, uri = http://calculator.dev/plane#
  6. OUT: Cookie::path = /
  7. IN: cookie = PHPSESSID=feb27189e1fe36592658c828f46a664d; expires=Sat, 04 Feb 2012 16:22:37 GMT, uri = http://calculator.dev/plane/display
  8. OUT: Cookie::path = /plane
  9. IN: cookie = PHPSESSID=feb27189e1fe36592658c828f46a664d; expires=Sat, 04 Feb 2012 16:24:10 GMT, uri = http://calculator.dev/plane/display#
  10. OUT: Cookie::path = /plane
  11. IN: cookie = PHPSESSID=15acaddee90b34f5027e1290d1476b70; expires=Sat, 04 Feb 2012 16:25:31 GMT, uri - http://calculator.dev/cart
    6: OUT: Cookie::path = /

From this you can see that the session cookie is reset between requests for:
/plane/display#
and
/cart

The cookie is discarded by CookieJar::updateFromResponse() because the 'path' of the session cookie in the jar (/plane) does not match the path of the response uri (/cart).

I cannot suggest a fix for this as I don't really understand how cookies are supposed to work and whether the session cookie should be treated as a special case. However, I have been able to workaround this as follows:

Modify Symfony\Component\BrowserKit\CookieJar
Comment out the following lines from CookieJar::allValues():
123 //if ($cookie->getPath() != substr($parts['path'], 0, strlen($cookie->getPath()))) {
124 // continue;
125 //}

As far as I can tell CookieJar is only used for browser simulation and as my app only uses the session cookie this should not result in any false positive tests.

Member

stof commented Apr 4, 2012

@intelliapps is it still valid or has it been solved since ?

@ghost

ghost commented Apr 7, 2012

Which version of Symfony2 does this relate to? 2.0 or 2.1?

@ghost

ghost commented Apr 7, 2012

Is this related to #3109?

The Symfony version is 2.0.4

Having looked at #3109 I don't think they're related.

Owner

fabpot commented Apr 20, 2013

Should be fixed by #7738

@fabpot fabpot closed this Apr 20, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment