FYI, when I've seen such problems in the past, I was usually able to implicate the "reject some/all cookies" user preference feature of the browser. There was a version of IE where that feature was terribly buggy but I've seen similar problems (with less frequency) with other versions of both IE and FireFox. That is why changing to a different domain can fix the problem.

Since your specific problem was fixed by going from perlmonks.org to www.perlmonks.org, it might instead be due to the somewhat subtle way cookies for "$X.$Y.$Z" might work on "$Y.$Z" and vice versa. For example, RFC2109 notes "Ordering with respect to other attributes (e.g., Domain) is unspecified" when multiple of the browser's cookies "apply".

So it is quite possible that logging in (which sends a cookie with no specified "domain" so the browser applies the default) sets a cookie for Domain=".www.perlmonks.org" but an existing cookie (from some previous visit) for Domain=".perlmonks.org" gets sent second by your browser (either by design or by chance or something in between) and I know (from reading the source code) that CGI::Cookie would silently override the first cookie with the second cookie and so your new login cookie would be rather useless.

Last time I played with how a specific browser dealt with having two cookies that differed only by "www.", I found that I could log in separately to each of www.perlmonks.org and perlmonks.org if I logged in to them in the correct order. Logging in to www.perlmonks.org will give you a cookie that doesn't impact perlmonks.org. So you can next log in to perlmonks.org and then be at the mercy of your browser's unspec'd behavior when you visit www.perlmonks.org.

Last time this came up, I was actually using 5 different cookies states simultaneously (some more often than other, obviously). I was logged in as tye to www.perlmonks.org. I was logged in as tye in stealth mode to perlmonks.org. I was similarly logged in two different ways as tye  for (www.)?perlmonks.com. And I was not logged in (for testing things as AnonyMonk) to perlmonks.net. So I didn't want to break this possibility.

Now that I more fully understand the subtle interactions, I think we should change the login cookies that we give out to include Domain=".perlmonks.$top" so that the "www." no longer matters. People will still be able to have separate cookie states for .org, .com, and .net (which is still a mixed blessing but is at least deterministic).

These days I'm not cookied for any *perlmonks.* domains. There are quite a few different ways to try to trick me or my browser into messing with PerlMonks. The site now has some protections in place against some of these tricks and I personally have other protections in place in the configurations of my browsers.

But I am also protected via "security through obscurity" because nobody should know what domain names I use to visit PerlMonks. My personal computers' "hosts" files have nonsense domain names assigned to the IP addresses that reach the PerlMonks web site.

So anybody who needs more than 3 simultaneous cookie states at PerlMonks will still be able to get them simply by updating their "hosts" file even after I fix logging in to www.perlmonks.$top so that it also applies to perlmonks.$top. Or, since we already covered how you can arrange to visit here via http://www.ginormi.ca/, new cookies will be made to set Domain=".$base" only if you visit via "www.$base" where $base =~ /[^.][.][^.]/.

FYI,

:-) .... yeah thanks for the expertise commentary tye.... it reminds me why i opted out of cgi and went to local gui's :-)

... upon further reflection as to what you said tye, one of my first thoughts was the option somewhere, which i saw, IIRC, to auto-prepend a www for you on sites that you accidently leave it off but need it. So.... a pseudo www is generated to access the page, but deeper into the security levels, the real strings must be exact matches. ...... zen and the art of Perl hacking ;-)

---

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku