Dear Lazyweb: Windows+IE tech support

[denny]

At work we have clients. It's a shame, because things would be much quieter without them. However, I'm given to understand that they pay our wages or something, so I suppose it's for the best really...

Said clients tend to be running Windows (XP mostly) and IE (6 or 7). They have a section of our site where they can log in and access restricted documents and so on. Or at least, where they should be able to log in. A number of them have complained that they can't log in - the system 'just takes me back to the login page over and over again'. At least one of them can log in to sitename.com but not www.sitename.com, which is particularly irritating.

My first guess was that they'd blocked cookies somehow, but getting them to set all the cookie options I can find in Internet Options to 'allow, yes please, woohoo, go go go' doesn't seem to have made any difference. Does IE have per-site cookie-blocking, or are there just the global settings? I couldn't find any per-site stuff, which confused me a bit.

Any suggestions on other things I could/should check?

Naturally, logging in to the site works perfectly from every PC we have in the office, which is Linux/Firefox1.5, Linux/Firefox2, Linux/IE6, Windows/Firefox1.5, Windows/IE5.5, Windows/IE6, Windows/IE7, MacOSX/Firefox2 and MacOSX/Safari. It also works from libellum's Windows machine at her place. I can't think of anything that would explain the problems our users are having other than PEBCAK, but I need to figure out which Problem Exists and how to fix it, so that I can explain it to the bit BCAK over the phone.

Comments

[naranek.livejournal.com]

Is there a (caching) proxy in the way? What's the domain and path on your cookies and do you have reverse DNS set up correctly? (No. No, it shouldn't, but that doesn't mean it isn't ..) You're not by any chance using POSTs for your login page, throwing out no cache control headers and expecting caches to categorise POST as uncacheable or something? Or issuing a different 302 and hoping the cache will notice the different target?

I vaguely remember we used to have problems with some copies of IE not loving the idea of having anything smaller than a domain name as a cookie path (and in fact being quite picky about whether you said foo.example.com or foo.example.com/). Oh, and occasionally deciding that they didn't love https redirects for no apparent reason.

[pooloftrees.livejournal.com]

IE7 is a pile of crap. I refuse to use it, and advise against it's use.

That said, I still have to support it. Firstly - your client should make sure that they have installed an optional update from Windows Update that fixes known HTTP authentication issues - that may be the issue. You can also get this update from Microsoft's Knowledge Base: KB904942 (http://support.microsoft.com/kb/904942).

I'll post more later...

[pooloftrees.livejournal.com]

cokephreak has already said about trusted sites (Tools -> Internet Options -> Security [tab]), but you may also want to add your site to allowed sites in the Privacy tab, to ensure that the cookies aren't getting blocked.

I hope that helps. I'll invoice your company later... :-p

[cokephreak.livejournal.com]

heh, we've done clever things to stop IE7 getting pushed out from MSupdate

NExt thing to try from whats been said is to try adding your site to their "Trusted sites"
After that check to see if they've got anything silly installed, like yahoo / google toolbars, as they take the liberty of blocking things they don't like for you

[http://users.livejournal.com/_nicolai_/]

Check your certificates match the servername; www.foo vs foo.
Self-signed doesn't cut it any more.
I suggest getting a wildcard certificate from someone like Comodo if you need one.

[denari.livejournal.com]

How about number of people logged in at same time? Oh and check EXACT IE versions inclduing service packs and suchlike