Forum Moderators: coopster

Message Too Old, No Replies

Weird problem with sessions - some variables not being saved

         

radiator251

12:12 am on Feb 7, 2010 (gmt 0)

10+ Year Member



I've had this problem on two separate occasions, and finally I've made a substantial effort to diagnose it, but to no avail.

What's happening is, I set a captcha code to a session variable like this:

...
$_SESSION['form_captcha_code'] = security_code();


...where security_code is a function that generates a random 5-character alphanumeric string. My problem is, when I go to access this variable on another page, specifically, the one that handles the form and verifies the CAPTCHA, the variable has an entirely different value than the one that I set it to.

I *think* this may have something to do with the fact that I set it to the return value of a function, rather than a value itself, so that might explain how the function is seemingly being called again at the very top of my handler page. However, I changed the way I set the variable to just calling "security_code();" and having the function itself set the session variable, and it still does the same thing.

I'm pulling out my hair over this. Does anyone have any ideas on why this would happen?

IanKelley

1:22 am on Feb 7, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



There's not really enough info in your post to say what's going on. I would guess that either you are assigning the session variable a second time somewhere else in the script (or on a subsequent page), or there is a bug in your code generator function. It seems unlikely that the problem is with the session itself.

radiator251

2:45 am on Feb 7, 2010 (gmt 0)

10+ Year Member



Update:

I did a test to see rather this was because I was referencing another variable or function in the definition.

I had one page with:


session_start();
$code = '12345';
$_SESSION['code'] = $code;


And another with:


session_start();
$code = '54321';
echo $_SESSION['code'];


And like I would have expected, the second page displayed "12345". So, the problem isn't with all variables like this, it's just with a select few, and I can't figure out the difference between the ones that work and the ones that don't. Does anyone have an idea?

Also, in its actual usage, when I manually set the session variable, instead of using a function, it saves across the pages without a problem. E.g., $_SESSION['form_captcha_code'] = '12345' works, but $_SESSION['form_captcha_code' = security_code(); and $_SESSION['form_captcha_code'] = ${some variable}; do not work.

radiator251

3:08 am on Feb 7, 2010 (gmt 0)

10+ Year Member



Sorry Ian, I didn't see your post before that update. I'll try to clarify.

The form in question has method="POST" and action="/handlers/form_handler.php". So right when the button is clicked, it goes to form_handler.php, where the session variable is getting reset somehow.

I'm 99% sure this isn't happening within the page itself, because at the very bottom I tested it with "echo $_SESSION['form_captcha_code']", and it is displaying the correct code. And, since the only thing above "echo $_SESSION['form_captcha_code']" on my form_handler.php page is "session_start();", I don't see how it could get reset on that page either.

radiator251

3:27 am on Feb 7, 2010 (gmt 0)

10+ Year Member



Ok, I found the problem.

I have a URL re-routing system, where everything that doesn't reference an existing file or directory is routed to index.php, and from there I call different initializing files and templates based on the URL. For some reason, even when I called a file that exists, such as the handler script, index was called first and set a new captcha code, and then the user was redirected to the page they requested.

I'll have to do some more research to find out how this occurs, but at least I know how to work around it for now.

rocknbil

3:32 am on Feb 7, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



It's possibly because of the PHPSESSID cookie. It might help to review a few things about sessions (which I got a stark reminder about yesterday.)

Most of the time, sessions use cookies. Otherwise, how would they keep a connection between the server and a given browser, right?

As with all cookies, the PHPSESSID cookie is not available for reading until the next page iteration after it's set.

You need another page AFTER setting a session var to get at it because:

Start session->sets cookie in browser.

Cookie is still in the browser so the server doesn't "know" what PHPSESSID to connect with.

Refresh page, browser sends PHPSESSID cookie to server . . . and connects with appropriate session ID.

I think you're experiencing something like this.

radiator251

4:03 am on Feb 7, 2010 (gmt 0)

10+ Year Member



Thanks rocknbil, I'll keep that in mind for my future problems. I did just figure out what the problem was though, and it had nothing to do with sessions, or even PHP for that matter.

My problem was, my htaccess file was set so any URL that referenced a non-existent file would be routed to index.php, and templates, initializers, etc would be called from there based on the URL. In my css code, one of my background properties was referencing an image that didn't exist anymore, so after the PHP ran on my page, the browser would try to load that image, and would then get routed to my index.php file, where the session variables would get reset as if the user were simply accessing a new page.

There's no feeling like squashing a bug after you've been hunting it for hours ;-)