Disappearing session variables

On Aug 5, 3:09*am, Geoff Berrow <blthe...@ckdog.co.uk> wrote:
> 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.

On Aug 5, 1:06*pm, Pink Pig <b...@grandcentralapartments.com> wrote:
> 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?

Message-ID:
<bdbbaaa0-ee6d-41c9-8276-341fde5e27d9@j22g2000hsf.googlegroups.com> from
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

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

give her a try

..oO(Pink Pig)

>On Aug 5, 3:09*am, Geoff Berrow <blthe...@ckdog.co.uk> wrote:
>> 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

Message-ID:
<08ed524e-d7ef-4b6e-8a66-40979a12ca6a@m44g2000hsc.googlegroups.com> from
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

On Aug 5, 5:36*pm, Michael Fesser <neti...@gmx.de> wrote:
> 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.

On Aug 5, 7:24*pm, Pink Pig <b...@grandcentralapartments.com> wrote:
> On Aug 5, 1:06*pm, Pink Pig <b...@grandcentralapartments.com> wrote:
>
> > 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

Pink Pig wrote:
> On Aug 5, 5:36 pm, Michael Fesser <neti...@gmx.de> wrote:
>> 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.
jstucklex@attglobal.net
==================

..oO(Pink Pig)

>On Aug 5, 5:36*pm, Michael Fesser <neti...@gmx.de> wrote:
>> 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