views:

232

answers:

3

Hi All,

I have a PHP site that uses a fairly common authentication scheme.

  • The entire login area requires ssl.
  • A user enters their username and pw, if they match the db, a session is started and a value set for them.
  • If they try to visit a page that requires authentication, it checks to see if that value is present in the session, and forwards them to the login page if it isn't.

We always get a few people that have trouble loggin in because they aren't set to use session cookies, or they have problems with the cache stroring the forward page, etc.

Lately, however, we have had a lot of people with IE who can't login. Fixing their session cookie settings and clearing the cache don't help, but they can login if they use firefox/opera on the same computer. I'm pretty sure it's a problem with IE, and not anything in between.

Does anyone know of any recent changes to IE 7 that would affect session cookies?

Update:

I did recently implement a session_regenerate_id() call immediately after login, as there are now some circumstances where a user may have an existing session that will be used, but that was quite some time ago.

A: 

I haven't heard anything. Though, this is precisely why I switched to using cookieless sessions on all my public projects. I believe ASP.Net has this built in but I prefer to use my own implementations. Passing querystring sessionid parameters from page to page and either tying it to a DB record or some other data store is far more reliable.

Spencer Ruport
And what do you use instead, may I ask?
Jarett
Edited my post. See above.
Spencer Ruport
You're really compromising security doing it that way, though. The session ID should be treated like a plaintext password, because while the session is active, that's basically what it acts like. Putting it in the querystring will get it saved in all kinds of public places: caches, proxy servers, the browser history, links the user copy/pastes into a forum, etc. I'd rather a few users can't use my application because they voluntarity turn off cookies than a few users' accounts get compromised.
Jarett
I like the cookie login too. I tend to keep pretty clean URLs, because I hate to have data shown to the casual user or stored anywhere I didn't intend it to be. Though I agree, it's a real pain when something suddenly changes...
Eli
+3  A: 

My first step would be to find a user who can log in with Firefox and not IE, and then run Fiddler against both to see the differences in the HTTP request/response pairs for the login process. That should, at least, give you a better idea of where to look.

DDaviesBrackett
+1  A: 

If IE's security settings are cranked up (which is common especially in corporate environments), or if the page that you're logging in to is in a frame or iframe, that could be what's keeping the cookie from saving. All you need to do is set P3P policy HTTP headers if that's the case. Here's the best description that I could find on how to implement them.

Jarett
Hmm, this could be it, since we don't have a p3p header. I'll implement that and see if it helps.
Eli