Session losing variables?

[Schraalhans Keukenmeester]

I am stomped with the following problem:

I have a script start.php and a second script proceed.php

Relevant (and working) sections of the code:

start.php

<?PHP
start_session() ;
// this string will later be used to check if
// proceed.php was invoked via the form below
$verif_str="abc defg";
$name_str="hijk lmn";
// Store these vars in the SESSION array.
$_SESSION['vstr']=$verif_str;
$_SESSION['nstr']=$name_str;
// output the form (in real case with correct html surrounding
// the form, doctype, header, body tags, all that)
echo"
<form action='proceed .php' method='POST'>
<input type='text' name='field_01' />
<input type='text' name='field_02' />
<input type='hidden' name='check' value='$verif_s tr' />
<input type='submit' />
</form>";
?>

proceed.php

<?PHP
start_session() ;
// read back session vars
$verif_str=$_SE SSION['vstr'];
$name_str=$_SES SION['nstr'];
// read back hidden form var and regular fields
$check_str=$_PO ST['check'];
$field01=$_POST['field01'];
$field02=$_POST['field02'];
// are these strings equal ? If not, stop processing.
if ($verif_str != $check_str)
exit ('Verification code incorrect');
// Strings match, so open logfile, exit if this fails.
$fp = @fopen('transac tion.log','a');
if ($fp===false)
exit ('Could not open file. Aborting.');
// write contents, for brevity additional error-checking is
// omitted here. This exists in the actual code.
fwrite($fp,"=== ===========\n") ;
fwrite($fp,"Ver ification string:".$verif _str."\n");
fwrite($fp,"Nam e string:".$name_ str."\n");
fwrite($fp,$fie ld01."\n");
fwrite($fp,$fie ld02."\n");
fclose($fp);
// rest of code, irrelevant to my issue
?>

The problem:

When I call the script start.php and submit the form data, 100 out of
100 'experiments' lead to a correct log entry being written. Both
strings $verif_str and $name_str contain the values assigned in start.php.

(For the record, I tried Konqueror, elinks and Firefox 1.5.0.5 for a
browser, on a Gentoo Linux machine. The acting server is a
Centos/Apache2.0.50/PHP4.3.4 combination)

However, if some/many of the OTHER users visiting the page fill out the
form, quite often, but not always, the session variables lose their
values in proceed.php. The form variables are properly transmitted though.

I have not been able to reproduce or explain this difference in
behaviour. yet I do believe I am making some mistake somewhere in my
code. I just fail to see it I guess.

(Please ignore the stupidity of what the code actually does and whether
that is good practice, the real case is somewhat more complicated and
makes more sense.)

Does anyone recognize this, see what's wrong and care to help me out?
Thanks a bunch in advance!!

Regards
Sh

[Rik]

Schraalhans Keukenmeester wrote:

I am stomped with the following problem:

I have a script start.php and a second script proceed.php

Relevant (and working) sections of the code:

start.php

<?PHP
start_session() ;
// this string will later be used to check if
// proceed.php was invoked via the form below
$verif_str="abc defg";
$name_str="hijk lmn";
// Store these vars in the SESSION array.
$_SESSION['vstr']=$verif_str;
$_SESSION['nstr']=$name_str;
// output the form (in real case with correct html surrounding
// the form, doctype, header, body tags, all that)
echo"
<form action='proceed .php' method='POST'>
<input type='text' name='field_01' />
<input type='text' name='field_02' />
<input type='hidden' name='check' value='$verif_s tr' />
<input type='submit' />
</form>";

>>

proceed.php

<?PHP
start_session() ;
// read back session vars
$verif_str=$_SE SSION['vstr'];
$name_str=$_SES SION['nstr'];
// read back hidden form var and regular fields
$check_str=$_PO ST['check'];
$field01=$_POST['field01'];
$field02=$_POST['field02'];
// are these strings equal ? If not, stop processing.
if ($verif_str != $check_str)
exit ('Verification code incorrect');
// Strings match, so open logfile, exit if this fails.
$fp = @fopen('transac tion.log','a');
if ($fp===false)
exit ('Could not open file. Aborting.');
// write contents, for brevity additional error-checking is
// omitted here. This exists in the actual code.
fwrite($fp,"=== ===========\n") ;
fwrite($fp,"Ver ification string:".$verif _str."\n");
fwrite($fp,"Nam e string:".$name_ str."\n");
fwrite($fp,$fie ld01."\n");
fwrite($fp,$fie ld02."\n");
fclose($fp);
// rest of code, irrelevant to my issue

>>

The problem:

When I call the script start.php and submit the form data, 100 out of
100 'experiments' lead to a correct log entry being written. Both
strings $verif_str and $name_str contain the values assigned in
start.php.

(For the record, I tried Konqueror, elinks and Firefox 1.5.0.5 for a
browser, on a Gentoo Linux machine. The acting server is a
Centos/Apache2.0.50/PHP4.3.4 combination)

However, if some/many of the OTHER users visiting the page fill out
the form, quite often, but not always, the session variables lose
their values in proceed.php. The form variables are properly
transmitted though.

I have not been able to reproduce or explain this difference in
behaviour. yet I do believe I am making some mistake somewhere in my
code. I just fail to see it I guess.

(Please ignore the stupidity of what the code actually does and
whether that is good practice, the real case is somewhat more
complicated and makes more sense.)

Does anyone recognize this, see what's wrong and care to help me out?
Thanks a bunch in advance!!

I don't really see anything wrong with your code. Have you been able to
check with ths users experiencing problems:
- What value the $_SESSION variable was?
- Wether they've disabled cookies?
- What happens if you just test wether a session works for them at all atm?

Grtz,
--
Rik Wasmus

[Schraalhans Keukenmeester]

Schraalhans Keukenmeester wrote:

I am stomped with the following problem:

I have a script start.php and a second script proceed.php

Relevant (and working) sections of the code:

start.php

<?PHP
start_session() ;

[snap]

Errrm, read session_start where I said start_session. Pardon the glitch.
Sh.

[Schraalhans Keukenmeester]

Rik wrote:

Schraalhans Keukenmeester wrote:

>I am stomped with the following problem:

I have a script start.php and a second script proceed.php

Relevant (and working) sections of the code:

start.php

<?PHP
start_session( );
// this string will later be used to check if
// proceed.php was invoked via the form below
$verif_str="ab cdefg";
$name_str="hij klmn";
// Store these vars in the SESSION array.
$_SESSION['vstr']=$verif_str;
$_SESSION['nstr']=$name_str;
// output the form (in real case with correct html surrounding
// the form, doctype, header, body tags, all that)
echo"
<form action='proceed .php' method='POST'>
<input type='text' name='field_01' />
<input type='text' name='field_02' />
<input type='hidden' name='check' value='$verif_s tr' />
<input type='submit' />
</form>";
proceed.php

<?PHP
start_session( );
// read back session vars
$verif_str=$_S ESSION['vstr'];
$name_str=$_SE SSION['nstr'];
// read back hidden form var and regular fields
$check_str=$_P OST['check'];
$field01=$_POS T['field01'];
$field02=$_POS T['field02'];
// are these strings equal ? If not, stop processing.
if ($verif_str != $check_str)
exit ('Verification code incorrect');
// Strings match, so open logfile, exit if this fails.
$fp = @fopen('transac tion.log','a');
if ($fp===false)
exit ('Could not open file. Aborting.');
// write contents, for brevity additional error-checking is
// omitted here. This exists in the actual code.
fwrite($fp,"== ============\n" );
fwrite($fp,"Ve rification string:".$verif _str."\n");
fwrite($fp,"Na me string:".$name_ str."\n");
fwrite($fp,$fi eld01."\n");
fwrite($fp,$fi eld02."\n");
fclose($fp);
// rest of code, irrelevant to my issue
The problem:

[snip]

I don't really see anything wrong with your code. Have you been able to
check with ths users experiencing problems:
- What value the $_SESSION variable was?
- Wether they've disabled cookies?
- What happens if you just test wether a session works for them at all atm?

1. I have (alas) not recorded the session variable itself in the logs
2 I have not been able to check (sofar) whether or not these users have
cookies disabled/enabled. I gather from your question cookies are a MUST
with sessions? No alternatives? At least one of them (them being the
users, not the sessions) is imho way too ignorant to even be able to
disable cookies let alone know why she would/should, leading me to
believe she has everything enabled and wide open on her box. Is it
feasible some popular firewall-like thingy blocks cookies?

3. The problem seems to recur every now and then. Most -if not all- HAVE
been able to use the form properly in the past, just suddenly they bump
into trouble, and once they do, each consecutive run immediately
following their first failed attempt shows the same loss of data.
All form data is utterly standard, just alphanumerical, no weirdly
formatted or otherwise dubious/suspect entries.

(In fact we are talking about a captcha script, displaying an image of 5
alphanumeric chars, the other half of the 'key' being parsed via the
session, the key itself via the form, and then reassembled and checked
in the proceed script)

Thanks sofar Rik! How rude would we be if we continued this in Dutch ? GRIN.

Sh.

[Rik]

Schraalhans Keukenmeester wrote:

Rik wrote:

>I don't really see anything wrong with your code. Have you been able
to check with ths users experiencing problems:
- What value the $_SESSION variable was?
- Wether they've disabled cookies?
- What happens if you just test wether a session works for them at
all atm?

1. I have (alas) not recorded the session variable itself in the logs

Too bad, it seems to me a problem with continuing a session.

2 I have not been able to check (sofar) whether or not these users
have cookies disabled/enabled. I gather from your question cookies
are a MUST with sessions? No alternatives? At least one of them (them
being the
users, not the sessions) is imho way too ignorant to even be able to
disable cookies let alone know why she would/should, leading me to
believe she has everything enabled and wide open on her box. Is it
feasible some popular firewall-like thingy blocks cookies?

Alternatives for cookies is offcourse a POST/GET variable. Since you're
using a form though, be sure you've configured PHP correctly to 'magically'
add the POST/GET variable so he user can continue his session and doesn't
start a new one over and over again.

3. The problem seems to recur every now and then. Most -if not all-
HAVE been able to use the form properly in the past, just suddenly
they bump
into trouble, and once they do, each consecutive run immediately
following their first failed attempt shows the same loss of data.

What if you unset($_SESSION );session_destr oy(); after a failure and then
let them retry?

All form data is utterly standard, just alphanumerical, no weirdly
formatted or otherwise dubious/suspect entries.

Well, then that probably isn't the problem.

Could you enable some kind of logging, to check wether the users
experiencing problems can continue sessions?

Thanks sofar Rik! How rude would we be if we continued this in Dutch

Verschrikkelijk asociaal ja ;)

--
Grtz,

Rik Wasmus

[Schraalhans Keukenmeester]

Schraalhans Keukenmeester wrote:
[for php code see original post, snipped]

Rik wrote:

>Schraalhans Keukenmeester wrote:

>I don't really see anything wrong with your code. Have you been able to
check with ths users experiencing problems:
- What value the $_SESSION variable was?
- Wether they've disabled cookies?
- What happens if you just test wether a session works for them at all atm?

Just something else that I think might perhaps be relevant:

The main page of the site I run this on is invoked by a URL:

Let's say http://www.this--domain.com, actually opening (framed):
http://www.my--server.com/index.html

The scripts themselves only deal with relative paths, no URLs, all
scripts are on the same server under the same docroot.

Is it possible the redirect has something to do with this as well???
Sh.

[Jerry Stuckle]

Schraalhans Keukenmeester wrote:

Schraalhans Keukenmeester wrote:
[for php code see original post, snipped]

>>Rik wrote:

>>>Schraalhan s Keukenmeester wrote:

>>>I don't really see anything wrong with your code. Have you been able to
check with ths users experiencing problems:
- What value the $_SESSION variable was?
- Wether they've disabled cookies?
- What happens if you just test wether a session works for them at all atm?

Just something else that I think might perhaps be relevant:

The main page of the site I run this on is invoked by a URL:

Let's say http://www.this--domain.com, actually opening (framed):
http://www.my--server.com/index.html

The scripts themselves only deal with relative paths, no URLs, all
scripts are on the same server under the same docroot.

Is it possible the redirect has something to do with this as well???
Sh.

Possible, but then it should fail more regularly and with more people.

Have those who are having the problem clear their cache and cookies. I
suspect that will help.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Erwin Moller]

Rik wrote:

>Thanks sofar Rik! How rude would we be if we continued this in Dutch

Verschrikkelijk asociaal ja ;)

ach, valt wel mee. :P

[Nico]

Have you tried closing the session once you don't need to change it any
more? I don't remember exactly but I think the function is named
something like session_write_c lose().
This simple step solves most of the "random" issues with php's sessions
as it allows other scripts to read the same session file.

[Schraalhans Keukenmeester]

Nico wrote:

Have you tried closing the session once you don't need to change it any
more? I don't remember exactly but I think the function is named
something like session_write_c lose().
This simple step solves most of the "random" issues with php's sessions
as it allows other scripts to read the same session file.

Thanks for the pointers, I have 'expanded' the logging data set for now
and added the suggested function. Now let's wait and see how things go
from here. I'll report back how I fared.

Rgds
Sh