Thanks for looking into this. I did more digging and found the real problem:
turns out it's setcookie() that's causing jwebunit to not read
or call the updated session id.
Test case:
public void testId() {
beginAt("http://testing.local/sess/form.php";);
setTextField("foo", "test data");
submit();
assertTextPresent("test data");
}
form.php:
<?php
session_start();
error_log("start id: " . session_id());
?>
<form name="test" method="POST" action="step1.php">
<input type="text" name="foo" value="" />
<input type="submit" name="submit" value="submit" />
</form>
step1.php:
<?php
session_start();
session_regenerate_id();
error_log("regenerated id: " . session_id());
$_SESSION['foo'] = $_POST['foo'];
setcookie("rick james", "Charlie Murphy", 0, "/"); // error here
header("Location:step2.php");
?>
step2.php
<?php
session_start();
error_log("final session id: " . session_id());
echo $_SESSION['foo'];
?>
Without the setcookie() call, the test passes.
However, setting a cookie will cause the error log to show
start session id = a, regenerated id = b, final id = a
Calling dumpCookies() will show the start and final session ids
to be the same as well.
Obviously, removing session_regenerate_id() will allow the test to
pass.
It doesn't seem to matter if you use a custom session cookie name either
(rather than the standard PHPSESSID name).
-----Original Message-----
From: Jevon Wright [mailto:je...@jevon.org]
Sent: Thursday, August 27, 2009 7:31 PM
To: Usage problems for JWebUnit
Subject: Re: [JWebUnit-users] tests fail with session_regenerate_id
Hi,
I couldn't reproduce your problem, could you post your scripts?
I tried it with the following JWebUnit test:
public void test1() {
getTestContext().setBaseUrl("http://localhost:8080//";);
beginAt("index.php");
IElement element = getElementByXPath("//b");
String initial = element.getTextContent();
clickButtonWithText("Submit Query");
element = getElementByXPath("//b");
String f = element.getTextContent();
assertNotSame(initial, f);
}
And the source code of the PHP files:
[index.php]
<?php session_start(); ?>
<html>
<b><?php echo session_id(); ?></b>
<form action="step1.php" method="get">
<input type="submit" value="Submit Query">
</form>
</html>
[step1.php]
<?php
session_start();
session_regenerate_id();
file_put_contents("session", session_id());
header("Location: step2.php");
[step2.php]
<?php
session_start();
if (file_get_contents("session") != session_id()) {
die("failed");
}
?>
<b><?php echo session_id(); ?></b>
--
Jevon
On Fri, Aug 28, 2009 at 3:34 AM, Jack Pham<jack.p...@infomart-usa.com> wrote:
> I had JWebUnit2.1 and tests that were working fine. After about a week or
> so, without
>
> changing anything, the tests started breaking. I finally traced the problem
> to session_regenerate_id()
>
> in the php application. The tests weren't catching the regenerated session
> id that was set,
>
> so the application couldn't find the session data through the tests.
> Obviously, manually running
>
> through the application worked fine. Finally I upgraded to 2.2 and the
> tests started passing
>
> again. Unfortunately, I needed to upgrade my PHP (which was using 5.2.2) to
> 5.2.4.
>
> The tests started breaking again. Once again, commenting out the
> session_regenerate_id()
>
> call allowed the tests to pass.
>
> So what is it in JWebUnit that's not catching the correct id?
>
> I'm using OS X 10.4.11
>
> Through JWebUnit, I fill out the form then use submit() (so I'm not using
> beginAt() or anything
>
> to load another page that might miss the session). Once the form is
> submitted, an intermediate
>
> php file processes the form (this is where the session_regenerate_id()
> occurs) which then sends
>
> the user to another php file that checks for the new session id before
> continuing.
>
> GET THE WHOLE STORY
>
> Criminal - Credit - Driving - Education - Employment - Drug - Assessments
>
> http://www.infomart-usa.com
>
> Ask about how we can automate your screening program!
>
>
>
> The information contained in this email is privileged, confidential and
> protected by disclosure. If you think that you have received this email
> message in error, please REPLY with "RECEIVED IN ERROR" in the Subject Box.
> We apologize for any inconvenience and thank you for your time.
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> JWebUnit-users mailing list
> JWebUnit-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jwebunit-users
>
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
JWebUnit-users mailing list
JWebUnit-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jwebunit-users
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
JWebUnit-users mailing list
JWebUnit-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jwebunit-users
