Session data gets lost in transit? Cache problems?

[jimoblak]

I have a basic script that prevents reaping of our database, offering only a few records to a user:

<?php
//START OF PAGE
session_start();
$_SESSION[counter]++;
if ($_GET[count]==&quot;reset&quot;){ $_SESSION[counter]=0; }

//LATER IN THE PAGE...
if ($_SESSION[counter]<=8) {
//DISPLAY DATA
}
?>

I can reset the counter by simply passing the URL of:

[URL unfurl="true"]http://www.domain.com/page.php?counter=reset[/URL]

The session counter does not seem to be consistently working. I have been debugging the script by placing the $_SESSION[counter] variable in the page title. I watch as it jumps from 1 to 2 to 1 to 3 to 4 to 5 to 5 to 6 to etc...

It seems like it is trying to do its thing but it may be going haywire on proxy/firewall caching. Can anyone explain why this is happening and how to fix? Is there some sort of PHP header trick or should I simply place a 'pragma nocache' meta tag in the HTML header? Or am I simply going in the wrong direction?

- - picklefish - -

 

[sleipnir214]

I've had problems before on a LAMP box with Mi&cent'ro$oft's proxy software.

My solution was to use Apache's content expiration module to tell proxies that PHP-script-derived content expires immediately.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!

 

[Dogers]

i might be a little out of date with the php versions here, but dont you need to
session_register("counter&quot
after starting the session?

ive always found sessions to be excessively picky for me..

 

[sleipnir214]

Dogers:
Not if you are directly referencing the elements of the $_SESSION superglobal array. In fact, the PHP online manual page on session_register() (

http://www.php.net/manual/en/function.session-register.php)

states explicitly to NOT use session_register() if you are referencing $_SESSION directly.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!

 

[vergilius]

Do you create variable $_SESSION[counter] some where ?
becouse if not, then i am not sure that you can just do $_SESSION[counter]++; ,

I think you need create variable, register it in session, and only then do with it what ever you need.

 

[sleipnir214]

The section of code that reads:

$_SESSION[counter]=0;

Both initializes the array element and registers it with the session system.

The only thing I do not see is code that takes care of the case where $_SESSION['count'] has not been created, but the "reset" command has not been sent. A situation, for example, should a user hit the page for the first time.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!

 

[jimoblak]

Sorry - I would have jumped in a bit sooner had I known there were responses. My email is being buggy today - which may also account for the oddities with my script. We have an aerial connection to the internet and the recent rainstorms have done some damage to our connection.

I was under the impression that simply stating:

$_SESSION[counter]++;

...would indicate that $_SESSION[counter] started as a zero value.

I'll try a conditional to create the initial zero value...

<?php
//START OF PAGE
session_start();

if (empty($_SESSION[counter])) { $_SESSION[counter]=0; }

$_SESSION[counter]++;
if ($_GET[count]=="reset"){ $_SESSION[counter]=0; }

//LATER IN THE PAGE...
if ($_SESSION[counter]<=8) {
//DISPLAY DATA
}
?>

- - picklefish - -

 

[jimoblak]

Nope - it still does not work - even after adding the new line to establish $_SESSION[counter], the counter is still jumping all over the place.

This seems to be a little distressing since this is a perfect application for sessions.

Following is my config if anyone can see any blatant errors:

PHP 4.2.3

session.auto_start : Off
session.cache_expire : 180
session.cache_limiter : nocache
session.cookie_domain : no value
session.cookie_lifetime : 0
session.cookie_path : /
session.cookie_secure : Off
session.entropy_file : no value
session.entropy_length : 0
session.gc_maxlifetime : 1440
session.gc_probability : 1
session.name : PHPSESSID
session.referer_check : no value
session.save_handler : files
session.save_path : /tmp
session.serialize_handler : php
session.use_cookies : On
session.use_trans_sid : 1

- - picklefish - -

 

[skiflyer]

I dunno, your code looks perfect to me, as do your settings (they'd be wrong on a windows box, but since it's working at all I'll assume you're on linux)

I think it makes sense to mention this sense it hasn't been mentioned yet, but does your script pass through any pages which do not call a session_start()? That can cause unexpected results. Are there any frames involved... again, funky results. (both deterministic, but funky none the less)

Other thing I can suggest is to actually open up your /tmp folder and watch the session files be created and changed, see if you can't notice a pattern, a specific time which a new file is created and shouldn't be for example.

G'luck
-Rob

 

[jimoblak]

Thanks for the info all.

All of this takes place on one page that acts upon itself with a form - there are no frames. Yes - it is served on Linux/Apache. I forgot to test it from home last night to see if it was just our buggy net connection at work. I will also tinker on my local dev server (WinXP/Apache) today but my concern is obviously with the live Linux production server.

- - picklefish - -

 

[DRJ478]

jimoblak,

One more debugging idea - I actually used it myself and it helped me find the cause of session inconsistencies:

Display the session ID and observe if it changes when the counter goes haywire. You can print_r the $_COOKIE data and $_SESSION.

 

[jimoblak]

Okay - I think I have resolved the situation to be that my computer is buggy. I tried the page on other computers at my location without difficulty.

While I will remain curious why my computer is buggy with sessions, I am content with moving on and assuming this script is okay for the rest of the world.

- - picklefish - -