views:

208

answers:

5

I have a login setup on a site that stores login information in PHP's $_SESSION, and additionally sets a two-week cookie with login information if a checkbox is checked. The user is considered logged in if valid login information is either submitted by POST or either cookie is true.

The behavior on FF3/Chrome is as intended, at least with the "Remember me" checkbox checked: log in anywhere and everywhere on the site you are treated as being logged in.

However, someone working with IE6 said that she logged on one place, clicked around on links to other sections of the site, and was asked to log in again. I ran into some trouble with my (Multiple IE) IE6, but I reproduced similar behavior on IE8, including setting Advanced Privacy Settings->Always allow session cookies, and otherwise set cookie permissions to be as tolerant as I could. The behavior was identical: log in one place in a way that should set both _SESSION and the two-week cookie, click on links to another pages, and the page presents you with a login screen because it doesn't recognize you as logged in. PHP is 5.2.8 on a Gentoo server.

Any suggestions or resources to getting recognized cookies?

--

[Added after checking on traffic with Fiddler:]

Thank you; I have downloaded Fiddler 2.

Fiddler is reporting Set-Cookie: [name]=deleted... on the logouts in question. I'm presently puzzled as to why. The included file that checks and displays a login screen only has one area where it can delete the relevant cookies, inside a conditional if $_GET['logout'] is set. I didn't see that happening, and when I put an error_log() statement inside the conditional before the statements to delete cookies, no additional messages appear to be being logged.

+3  A: 

Couple of suggestions

  • Try using Fiddler or similar to examine the HTTP requests and responses to see the cookies being sent and transmitted. This provide more insight into what is going wrong
  • Try having your app output a P3P header, e.g. header('P3P: CP="CAO PSA OUR"');
Paul Dixon
esp. look what has changed between "it's working" and "you're not logged in". What cookies did the client receive in the last response and what cookies is it sending. Fiddler is an excellent tool for that.
VolkerK
I'd welcome any comments on what I've found with Fiddler ("Set-Cookie: login=deleted...") at places I can't find anything like cookie expiration in the PHP.
JonathanHayward
+1  A: 

You'll need to be more specific. Find out exactly how you can replicate this behaviour on both browsers, and you've found your bug. For instance, there might be one or two pages where you're failing to call session_start().

It's important to remember that, if your particular $_SESSION variable is not being seen, and causing a redirect to your login, it's most probably part of your system that is broken.

karim79
+2  A: 

One thing that's kinda subtle that may jump out and bite you is that IE doesn't allow domain names with underscores (ie: developer_1_test.example.com) while other browsers let you get away with this. You're not v.likely to do this in production but it's an easy oversight to make in a development environment where you're setting up a bunch of vhosts for different developers/code branches/etc.

Sean McSomething
+1  A: 

The first thing I check when this happens is that the domain parameter for the setcookie() function is set properly.

I've seen instances where the cookie domain is set to 'example.com' but the site is being accessed via 'www.example.com'.

For example if you logged into the page at example.com, then clicked a link that took you to a page on www.example.com, you would no longer be logged in.

The workaround is to either make sure all your internal linking is consistent or that you set your cookie with '.example.com' which will enable the cookie for all subdomains.

cOle2
+1  A: 

What I eventually found was as follows: Firefox and IE were behaving differently because they were treating caching differently when a missing document was within the 14 day Expires: headers that had been set.

Firefox was apparently checking once for missing data, and then not requesting it again.

IE, on the other hand, kept on checking for an item a stylesheet gave the wrong path for, got 404 pages, and the custom 404 page did a boilerplate invitation to log in that triggered the user being logged out (perhaps not the best boilerplate). I guess the stylesheet was cached, but IE kept on asking for items that were missing.

So it was caching differences plus indirect inclusion plus 404 page behavior.

JonathanHayward