Disappearing session variables

[Pink Pig]

I'm trying to track down an annoying problem that only occurs when I
access my pages on a remote server using IE6. If I run instead run
from localhost, IE6 works fine, and if I use another browser on the
remote site, there are no problems.

I'm not really looking for help debugging. I'd just like to be pointed
in the right direction.

Essentially, what happens is this. When I start up (i.e. load
index.php on my site), I am logged out. When I log in, I go to
logincheck.php, which validates the login and transfers control back
to index.php with a few session variables set to indicate that I am
logged in. Up to here, everything works with all browsers and
locations. Next, I execute a database search, which goes to
searchresults.p hp to do the actual work, stuffs the results into
session variables, and returns to index.php. When I do this on the
remote site using IE6, the session variables set by the search are
present, but the login variables have been lost, so that I appear to
be once again logged out.

I've tried with both register_global s = On and register_global s = Off
with no change of behavior.

Does anyone have a clue what could be happening to cause this? For the
record, there are differences between localhost and the remote site.
I'm running PHP 5.2.3 locally, but the remote version is 5.0.5. There
may be other relevant differences as well.

[Jerry Stuckle]

Pink Pig wrote:

I'm trying to track down an annoying problem that only occurs when I
access my pages on a remote server using IE6. If I run instead run
from localhost, IE6 works fine, and if I use another browser on the
remote site, there are no problems.

I'm not really looking for help debugging. I'd just like to be pointed
in the right direction.

Essentially, what happens is this. When I start up (i.e. load
index.php on my site), I am logged out. When I log in, I go to
logincheck.php, which validates the login and transfers control back
to index.php with a few session variables set to indicate that I am
logged in. Up to here, everything works with all browsers and
locations. Next, I execute a database search, which goes to
searchresults.p hp to do the actual work, stuffs the results into
session variables, and returns to index.php. When I do this on the
remote site using IE6, the session variables set by the search are
present, but the login variables have been lost, so that I appear to
be once again logged out.

I've tried with both register_global s = On and register_global s = Off
with no change of behavior.

Does anyone have a clue what could be happening to cause this? For the
record, there are differences between localhost and the remote site.
I'm running PHP 5.2.3 locally, but the remote version is 5.0.5. There
may be other relevant differences as well.

This is strange - the browser you're using doesn't have anything to do
with the session data - only the session id is kept in a cookie. The
data itself is on the server, and should be completely independent of
anything else in the browser.

The whole thing makes no sense at all.

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

[Pink Pig]

On Aug 3, 1:36*pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:

The whole thing makes no sense at all.

I know -- that's why I'm beating my head against the wall.

The last time I had a baffling problem like this, it turned out to be
an unmatched apostrophe in a string, but this time I've validated the
HTML both before and after, and there are no errors to be found there.

[Jerry Stuckle]

Pink Pig wrote:

On Aug 3, 1:36 pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:

>The whole thing makes no sense at all.

I know -- that's why I'm beating my head against the wall.

The last time I had a baffling problem like this, it turned out to be
an unmatched apostrophe in a string, but this time I've validated the
HTML both before and after, and there are no errors to be found there.

That wouldn't be in the html - html has nothing to do with session data.

I could understand if the session information was related to the server
- for instance, you might be storing too much data in the session in the
failing case. But again, this has nothing to do with the browser,
unless you're storing browser-related information in the session.

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

[Pink Pig]

I'm now pursuing the theory that there's something going on in the
get_browser() function under IE that's causing my problems.
Incidentally, can anyone explain why, when I access a page with IE6,
the value of $_ENV["HTTP_USER_AGEN T"] says that the browser is Mozilla/
4.0?

[Andrew]

IE6 returns:

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

as it's HTTP_USER_AGENT . Google "HTTP_USER_AGEN T" to get some
references/lists to possible values for the HTTP_USER_AGENT from popular web
browsers.
"Pink Pig" <bi**@grandcent ralapartments.c omwrote in message
news:7c******** *************** ***********@79g 2000hsk.googleg roups.com...

I'm now pursuing the theory that there's something going on in the
get_browser() function under IE that's causing my problems.
Incidentally, can anyone explain why, when I access a page with IE6,
the value of $_ENV["HTTP_USER_AGEN T"] says that the browser is Mozilla/
4.0?

[The Hajj]

it sounds stupid, but double check that you have session_start()

I did this to myself the other as I was building the front end first
then the backend, made a new script and forgot session_start, DOH!

[Pink Pig]

On Aug 4, 4:57*pm, The Hajj <hajji.hims...@ gmail.comwrote:

it sounds stupid, but double check that you have session_start()

I did this to myself the other as I was building the front end first
then the backend, made a new script and forgot session_start, DOH!

Sorry, I'm battling with the stupid accessibility icon that somebody
thought was a good idea. The last time I tried to reply, it failed at
least 8 times. Maybe somebody should try to make sure that the code is
actually readable.

[Pink Pig]

On Aug 4, 4:57*pm, The Hajj <hajji.hims...@ gmail.comwrote:

it sounds stupid, but double check that you have session_start()

I did this to myself the other as I was building the front end first
then the backend, made a new script and forgot session_start, DOH!

OK, I got a message through, so I'll try again.

I have a session_start at the beginning of every file. It's not
literally the first statement, since I put it into a common header
that gets included in every file, but it works correctly under Firefox
and Opera, so I don't think that that's the problem.

The closest thing that I've heard to a possible explanation is that if
you don't explicit write out the session variables at the end of a
page, then it is possible that the new page is being loaded before the
old page has properly closed. I added an explicit session_write_c lose
everywhere just in case, but that didn't help. FWIW, the behavior is
consistent -- it always fails in exactly the same way every time.

[Geoff Berrow]

Message-ID:
<a7************ *************** *******@s50g200 0hsb.googlegrou ps.comfrom
Pink Pig contained the following:

>The closest thing that I've heard to a possible explanation is that if
you don't explicit write out the session variables at the end of a
page, then it is possible that the new page is being loaded before the
old page has properly closed. I added an explicit session_write_c lose
everywhere just in case, but that didn't help. FWIW, the behavior is
consistent -- it always fails in exactly the same way every time.

You mentioned the get_browser() function. Is your script designed to
react to different browsers in any way?
--
Geoff Berrow 011000100110110 0010000000110
001101101011011 001000110111101 100111001011
100110001101101 111001011100111 010101101011
http://slipperyhill.co.uk