By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,213 Members | 1,105 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,213 IT Pros & Developers. It's quick & easy.

Disappearing session variables

P: n/a
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.php 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_globals = On and register_globals = 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.
Aug 3 '08 #1
Share this Question
Share on Google+
24 Replies


P: n/a
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.php 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_globals = On and register_globals = 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*******@attglobal.net
==================

Aug 3 '08 #2

P: n/a
On Aug 3, 1:36*pm, Jerry Stuckle <jstuck...@attglobal.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.
Aug 3 '08 #3

P: n/a
Pink Pig wrote:
On Aug 3, 1:36 pm, Jerry Stuckle <jstuck...@attglobal.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*******@attglobal.net
==================
Aug 3 '08 #4

P: n/a
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_AGENT"] says that the browser is Mozilla/
4.0?
Aug 4 '08 #5

P: n/a
IE6 returns:

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

as it's HTTP_USER_AGENT. Google "HTTP_USER_AGENT" to get some
references/lists to possible values for the HTTP_USER_AGENT from popular web
browsers.
"Pink Pig" <bi**@grandcentralapartments.comwrote in message
news:7c**********************************@79g2000h sk.googlegroups.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_AGENT"] says that the browser is Mozilla/
4.0?

Aug 4 '08 #6

P: n/a
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!
Aug 4 '08 #7

P: n/a
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.
Aug 5 '08 #8

P: n/a
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_close
everywhere just in case, but that didn't help. FWIW, the behavior is
consistent -- it always fails in exactly the same way every time.
Aug 5 '08 #9

P: n/a
Message-ID:
<a7**********************************@s50g2000hsb. googlegroups.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_close
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 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
http://slipperyhill.co.uk
Aug 5 '08 #10

P: n/a
On Aug 5, 3:09*am, Geoff Berrow <blthe...@ckdog.co.ukwrote:
You mentioned the get_browser() function. *Is your script designed to
react to different browsers in any way?
Very slightly. If the browser is IE, then I load a different style
sheet, but that's it. I was a bit leery of get_browser() anyway, so I
switched to HTTP_USER_AGENT instead, and loaded a different style
sheet for HTTP_USER_AGENT == "Mozilla/4.0 ..."

There are some differences, e.g. the content of the database is
different between the two hosts, but I can't see why it works with
Firefox and Opera but not IE. My daughter tested it with IE7, and
reports that it behaves the same as IE6 in this case.

I've googled this issue a lot, and it seems to be a common problem,
but the proposed solutions seem a bit ad hoc to me -- I always hate
making a problem go away without figuring out the cause, since it
usually comes back to bite me later.

I added a bit of debugging code to track the _SESSION keys at various
points. I should make a table of the expected versus actual results,
so let me give it a shot here:

Initially | After login | After search
Expected: <none | pdata;sid;prospectID |
pdata;sid;prospectID;srchlast;sqlvars
Actual: <none | pdata;sid;prospectID | srchlast;sqlvars

Note that the lost keys were the ones set by the login -- the search
worked fine, and set the keys 'srchlast' and 'sqlvars'. The search
results were identical.

I forgot to check session_id() -- I'll add that and check again.
Aug 5 '08 #11

P: n/a
On Aug 5, 1:06*pm, Pink Pig <b...@grandcentralapartments.comwrote:
I forgot to check session_id() -- I'll add that and check again.
Well, this narrows it down a bit. When I run with firefox, I get the
following results:

Initially: "session_id() =
153bf8b7c6d6377db439e366bffd447b","session_keys = "
After login: "session_id() =
153bf8b7c6d6377db439e366bffd447b","session_keys =
pdata;sid;prospectID"
After search: "session_id() =
153bf8b7c6d6377db439e366bffd447b","session_keys =
pdata;sid;prospectID;srchlast;sqlvars"

This is what I expected. With IE6, however, I get:

Initially: "session_id() =
f00a1f91999a3058892c6f8ad2ba69d6","session_keys = "
After login: "session_id() =
373dfdd48d5276a8fa31e2c0bebfcb75","session_keys =
pdata;sid;prospectID"
After search: "session_id() =
f085ef49aba74f94e21107728e597e9d","session_keys = srchlast;sqlvars"

So why is IE causing PHP to create a new session_id() each time?
Aug 5 '08 #12

P: n/a
Message-ID:
<bd**********************************@j22g2000hsf. googlegroups.comfrom
Pink Pig contained the following:
>So why is IE causing PHP to create a new session_id() each time?
Something to do with the way you are accessing the database? IE seems
to be treating as if you were accessing a different server. I'm just
guessing here.

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
http://slipperyhill.co.uk
Aug 5 '08 #13

P: n/a
might have found a solution
http://genotrance.wordpress.com/2006...rnet-explorer/

give her a try
Aug 5 '08 #14

P: n/a
..oO(Pink Pig)
>On Aug 5, 3:09*am, Geoff Berrow <blthe...@ckdog.co.ukwrote:
>You mentioned the get_browser() function. *Is your script designed to
react to different browsers in any way?

Very slightly. If the browser is IE, then I load a different style
sheet, but that's it. I was a bit leery of get_browser() anyway, so I
switched to HTTP_USER_AGENT instead, and loaded a different style
sheet for HTTP_USER_AGENT == "Mozilla/4.0 ..."
Such browser sniffing will _never_ work reliable. Drop that.
Instead use conditional comments to include IE-only stylesheets.

Micha
Aug 5 '08 #15

P: n/a
Message-ID:
<08**********************************@m44g2000hsc. googlegroups.comfrom
The Hajj contained the following:
>might have found a solution
http://genotrance.wordpress.com/2006...rnet-explorer/

Some good stuff there. The underscore thing is a bit of a surprise.

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
http://slipperyhill.co.uk
Aug 5 '08 #16

P: n/a
On Aug 5, 5:36*pm, Michael Fesser <neti...@gmx.dewrote:
Such browser sniffing will _never_ work reliable. Drop that.
Instead use conditional comments to include IE-only stylesheets.
Let me see if I understand you here. You're saying that I should adopt
a non-standard MS "feature" rather than use sensible PHP code. I've
read up on it a bit. There's no clean way to create a negative
conditional, that is, I can't specify a conditional comment that
includes code only if the browser is not IE. There's a very dirty way
to do it, based on the fact that non-MS browsers catch and suppress
certain errors in a way that differs from the current implementation
of IE.

I've spent enough time in my life chasing moving targets. I'm
certainly not going to add any code that will almost certainly break
in a few years. Where possible, I use the jQuery ?.browser.* booleans
to detect the browser, since if this breaks, somebody else will fix it
quicker that I could.

It's unrelated to my real problem, anyway.
Aug 6 '08 #17

P: n/a
On Aug 5, 7:24*pm, Pink Pig <b...@grandcentralapartments.comwrote:
On Aug 5, 1:06*pm, Pink Pig <b...@grandcentralapartments.comwrote:
I forgot to check session_id() -- I'll add that and check again.

Well, this narrows it down a bit. When I run with firefox, I get the
following results:

Initially: * *"session_id() =
153bf8b7c6d6377db439e366bffd447b","session_keys = "
After login: *"session_id() =
153bf8b7c6d6377db439e366bffd447b","session_keys =
pdata;sid;prospectID"
After search: "session_id() =
153bf8b7c6d6377db439e366bffd447b","session_keys =
pdata;sid;prospectID;srchlast;sqlvars"

This is what I expected. With IE6, however, I get:

Initially: * *"session_id() =
f00a1f91999a3058892c6f8ad2ba69d6","session_keys = "
After login: *"session_id() =
373dfdd48d5276a8fa31e2c0bebfcb75","session_keys =
pdata;sid;prospectID"
After search: "session_id() =
f085ef49aba74f94e21107728e597e9d","session_keys = srchlast;sqlvars"

So why is IE causing PHP to create a new session_id() each time?
Another guess: One other thing that might be it is security zones.
I've been having similar problems earlier when temporarily moving a
site to a different server - we used a frame for redirection so that
the URL in the address bar would remain the same. Evil, maybe, but it
was the only way to keep the customer happy at the time.

All of a sudden people had to re-login at every page (i.e. the session
was re-made every time). The problem was that IE decided that pages
living in different frames and doing things with cookies are not
secure (but something more specific, i forgot the details). Adding a
P3P header (a digital way of telling a browser "yeahyeah, nono, we
won't sell personal information to the mafia") solved it. I believe -
my memory is rusty here. Check the security zone IE displays for the
site. I believe that there should also be some button that says why IE
thinks the site isn't to be trusted. If that's the case, of course.

Egbert
Aug 6 '08 #18

P: n/a
Pink Pig wrote:
On Aug 5, 5:36 pm, Michael Fesser <neti...@gmx.dewrote:
>Such browser sniffing will _never_ work reliable. Drop that.
Instead use conditional comments to include IE-only stylesheets.

Let me see if I understand you here. You're saying that I should adopt
a non-standard MS "feature" rather than use sensible PHP code. I've
read up on it a bit. There's no clean way to create a negative
conditional, that is, I can't specify a conditional comment that
includes code only if the browser is not IE. There's a very dirty way
to do it, based on the fact that non-MS browsers catch and suppress
certain errors in a way that differs from the current implementation
of IE.

I've spent enough time in my life chasing moving targets. I'm
certainly not going to add any code that will almost certainly break
in a few years. Where possible, I use the jQuery ?.browser.* booleans
to detect the browser, since if this breaks, somebody else will fix it
quicker that I could.

It's unrelated to my real problem, anyway.
But Micha is correct. There is no way to reliably sniff the browser.

You can use his suggestion, or write css and html which works in every
browser. But your browser sniffing idea is doomed to failure from the
outset.

Maybe that's why you've spent so much time chasing moving targets. I
don't use it, and spend no time at all chasing moving targets.

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

Aug 6 '08 #19

P: n/a
..oO(Pink Pig)
>On Aug 5, 5:36*pm, Michael Fesser <neti...@gmx.dewrote:
>Such browser sniffing will _never_ work reliable. Drop that.
Instead use conditional comments to include IE-only stylesheets.

Let me see if I understand you here. You're saying that I should adopt
a non-standard MS "feature" rather than use sensible PHP code.
Exactly. The "feature" in IE is proprietary, but it is well documented
and behaves in a defined way, while your "sensible" PHP code is just an
unreliable hack. You don't know at all whether it really is an IE or any
other user agent the just identifies himself as IE. The UA string could
be anything, while CCs are definitely only supported in IEs.
>I've
read up on it a bit. There's no clean way to create a negative
conditional, that is, I can't specify a conditional comment that
includes code only if the browser is not IE. There's a very dirty way
to do it, based on the fact that non-MS browsers catch and suppress
certain errors in a way that differs from the current implementation
of IE.
You said you want to include IE-only CSS, you didn't mention the other
way round in your OP. Why would you need that? Usually only IE needs
some fixes. Anyway, there is a way to accomplish this with valid markup.

http://www.456bereastreet.com/archiv...onal_comments/
>I've spent enough time in my life chasing moving targets.
Then you shouldn't use browser sniffing.
>I'm
certainly not going to add any code that will almost certainly break
in a few years.
Sniffing the UA does exactly that. Often enough I've seen sites that
told me that my browser "is not supported". After making him identify as
IE, the site "let me in". That's just stupid and perfectly shows how
unreliable such sniffing is.
>Where possible, I use the jQuery ?.browser.* booleans
to detect the browser, since if this breaks, somebody else will fix it
quicker that I could.
jQuery is even more of an ugly hack with its browser sniffing. With
every new browser the code has to be adjusted to accomodate for new UA
strings. That's not what good and reliable code should do. The keyword
is not browser detection, but feature detection. The IE CCs fall into
the last category and are the preferred way for adding IE-only stuff.
They simply work, don't have to be adjusted after an update and won't
break in a few years.

Micha
Aug 6 '08 #20

P: n/a
On Aug 6, 1:20*am, Pink Pig <b...@grandcentralapartments.comwrote:
It's unrelated to my real problem, anyway.
Let me repeat that: IT'S UNRELATED To MY REAL PROBLEM, ANYWAY. I don't
care about browser detection. I can detect browsers well enough for
the time being. What I want to know is why IE rejects session cookies
sometimes, and what can I do about it. Sheesh.
Aug 8 '08 #21

P: n/a
Is it fair to assume that nobody with any knowledge of the internal
working of either PHP or IE ever reads the messages in this group?

Aug 8 '08 #22

P: n/a
Pink Pig wrote:
Is it fair to assume that nobody with any knowledge of the internal
working of either PHP or IE ever reads the messages in this group?
fairly fair.

If you are lucky a real programmer will be stuck with a half hour
compile on something and wander in: otherwise you are stuck with Stuckle.

Whose generic perm one from four responses are

- try googling
- try asking in the right NG
- try turning error reporting on.
- RTFM

And if those don't send you packing, will turn the conversation around
to one of the few things he does know about.
Aug 8 '08 #23

P: n/a
Pink Pig wrote:
Is it fair to assume that nobody with any knowledge of the internal
working of either PHP or IE ever reads the messages in this group?

I don't think anyone outside of Microsoft knows how IE works internally.
And you don't need to know the inner workings of PHP.

So your problem looks like the session cookie is not being sent from IE
to the server. You can verify this with an IP trace, if you need to.
But that's going a ways.

What do you have for the following in your php.ini file:

session.use_cookies
session.use_only_cookies
session.name
session.auto_start
session.cookie_lifetime
session.cookie_path
session.cookie_domain
session.use_trans_sid

Also, what are your privacy settings in IE for internet sites - are you
using one of the standard settings, or a custom one?

P.S. If you're not sure which php.ini file you are using, php_info()
will show you which it is, as well as the settings for all of the above.

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

Aug 9 '08 #24

P: n/a
Geoff Berrow 提到:
Message-ID:
<08**********************************@m44g2000hsc. googlegroups.comfrom
The Hajj contained the following:
>might have found a solution
http://genotrance.wordpress.com/2006...rnet-explorer/


Some good stuff there. The underscore thing is a bit of a surprise.
IT manager 蛇***眼edmund yau (email擬似ya******@hotmail.com)
全香港最濺IT Manager, 見*著西裝返工. 著得好過佢就問**竟點諗, *小人,
痴撚線
5:00pm俾個job*做, 跟住就自己做到11點搞掂佢, 第2日就小*, 話*搞唔掂, 唔
撚洗放工呀

最撚柒就係呢條友啦, 搞個爛網出黎, 大家去睇下:
網址擬似www.funzy.com

有幾爛? 仆街, 用IE6開會*機架, 真係唔撚知用乜野skill可以寫撚到hang .

成條team朝9晚10, 搞個爛網得個2個function仔, 唔係hang機就係*link, 仲話寫
web要都唔知乜撚野skill set, 食屎啦, 小*生寫個web都唔撚會hang機啦

個個同事想放工都要驚呢樣驚個樣, *張*o的青春濺賣就唔撚好叫人一齊 *濺
賣, 人地都有屋企, *唔撚放工就*o既事, 除撚左打工都唔撚知搞個web未, 屎坑關刀

大家多多張呢個網發佈出去, 聲討呢種小人

Counter
1
Aug 12 '08 #25

This discussion thread is closed

Replies have been disabled for this discussion.