|
Re: Re: Warn people who have perlmonks in a URL?
by sauoq (Abbot) on Nov 09, 2003 at 01:57 UTC
|
this strikes me as either a browser bug or possibly a design flaw in the cookie specification.
It's neither. If anything, it's a bug in the way perlmonks is implemented. Apparently, the cookie sent is dependent on the server requested. It might be better to always send a cookie for the domain instead.
Note that if you are logged into perlmonks.org and a link takes you to www.perlmonks.org it will work just fine. It's only the other direction that breaks.
As far as the .com and .net domains... I'd be interested in hearing the reasoning behind why those TLDs don't just do a refresh/redirect to the .org domain.
That's a good question. I'll be interested in hearing the answer to that as well. I suspect it is an attempt to be friendly to clients that don't handle redirects transparently (or at all.) But, I think redirecting the other domains makes sense.
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
|
|
If anything, it's a bug in the way perlmonks is implemented. Apparently, the cookie sent is dependent on the server requested. It might be better to always send a cookie for the domain instead.
In other words, you're saying that they *can* share the
cookie. If that is the case, I think it would be better
to have them do so, than to try to train users to deal
with the fact that they don't. (Yeah, I know, I'm not
the poor admin who has to implement all these crazy
demands the users have...)
I suspect it is an attempt to be friendly to clients that don't handle redirects transparently (or at all.)
The standard way to deal with that is to send, along
with the refresh/redirect, a small page containing
a link. But I suspect very few users would ever see
the link, because all the major graphical browsers
can handle refresh since about 1995, and people who
use Lynx generally have been around on the net for a
little while and probably aren't going to be trying
to use a .com TLD to access a site like perlmonks,
unless they're either fooling around or testing the
site. (I'm assuming here that in addition to an HTTP
refresh header you also include an http-equiv refresh
in the <head> section of the document.
With doing both those things, browser support is
near universal.) I'm trying to imagine a Lynx user
who would think of perlmonks and immediately guess,
"It's probably a commerce site." A surreal notion.
But if you include the link in the response along
with the refresh, you cover even this edge case.
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
| [reply]
[d/l]
[select] |
|
|
No, I don't want www.perlmonks.org and perlmonks.org to share a cookie. I don't see any advantage to that. The cookie "problem" is only due to people making links with hard-coded site information and we can address that source of the problem so what advantage is there to also addressing the same problem in a different way that doesn't address it very well?
But the real reason I don't want to do this is because being able to have multiple cookies is an advantage. Every user can justify having 3 different cookies: logged out (no cookie -- when you want to see how your node looks to the average user), logged in, and logged in using "ticker" mode so that they don't show in "Other Users" (useful when you want to read/research/whatever but aren't paying any attention to the chatterbox and so don't want others to think you are hanging out when you won't notice them trying to chat with you).
Now, three cookies goes well with three domains (.org, .com, and .net). But I need more than one account (tye is not in gods because it is a bad idea to spend all day as superuser) and several other people have accounts such as thepen and im2 that are used for special purposes. Some people might share a computer and have enough trust that they share a computer login and each have permanent cookies to PerlMonks at different domains. Several people have "joke" accounts that they try to be humorous with (and now we are close to the type of "extra accounts" that are discouraged and can even get you into trouble...). So there are at least several case where having 4 (or perhaps more) cookies can be useful. I'm quite glad that I can have 6 cookies (I use 4 pretty regularly and sometimes use more).
www.perlmonks.org is tye. perlmonks.org is "stealth" tye who is ignoring the chatterbox. www.perlmonks.com is tye and perlmonks.com is "stealth" tye . www.perlmonks.net is AnonyMonk and perlmonks.net is an extra for when I need to test something that I can't test as any of the above.
And this could become even more useful if we go forward with vague plans about being able to have more options in a cookie (such as limited powers or custom "user settings")...
| [reply] |
|
|
|
|
|
|
In other words, you're saying that they *can* share the cookie.
Yes, www.perlmonks.org and perlmonks.org can share a cookie. And they do, so long as you log into perlmonks.org rather than www.perlmonks.org. Similarly with the .net and .com pairs. What can't be done is sharing cookies across domains. There are a number of reasons the spec doesn't allow for that, security not least among them.
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
|
|
Note that if you are logged into perlmonks.org and a link takes you to www.perlmonks.org it will work just fine. It's only the other direction that breaks
What you're seeing is the domain value of the cookie (see CGI::Cookie). By default, the domain is the machine you're on. You can explicitly set if anywhere up your food chain. So, as an example - www.perlmonks.org can set it's domain value to perlmonks.org but perlmonks.org cannot set it's domain value to www.perlmonks.org. If you log into perlmonks.org, www.perlmonks.org can see the cookie.
Oren
| [reply] |
|
|
What you're seeing is the domain value of the cookie (see CGI::Cookie).
Yes, exactly. And that's what I meant when I said, "Apparently, the cookie sent is dependent on the server requested. It might be better to always send a cookie for the domain instead."
When the cookie's domain attribute is set to the domain name of the server, the cookie is often referred to as a "domain cookie" and when it is set to the hostname, the cookie is sometimes called a "host cookie" or "server cookie".
The word "domain" has dual meaning as one of the cookie attributes and as a DNS term.
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
|
|
Note that if you are logged into perlmonks.org and a link takes you to www.perlmonks.org it will work just fine.
No it doesn't. Not on Firebird ("Mozilla Lite") on Win32. I just tested it. While I'm at it: it doesn't work on the normal Mozilla, Netscape 7, Netscape 4.79.
However, it does seem to work on MSIE5.5. Uncle Bill seems to have done it his own way, once again.
BTW I think that it's possible to specify cookies that do work for both domains. But you have to specify it in a specific way... something to do with a leading dot. For details, see the cookies RFC
| [reply] |
|
|
No it doesn't.
Mea culpa. I should know better than to test on just one (lame) platform before making a statement like that. It was, unfortunately, the only platform I had immediately available. Sigh.
Uncle Bill seems to have done it his own way, once again.
I agree that the behavior seems to be broken and I'm anything but a defender of the evil empire, but I bet Hanlon's Razor applies in this case. It looks like it may have originated with a poorly chosen example in the original Netscape cookie spec. The example given is:
A domain attribute of "acme.com" would match host names "anvil.acme.com" as well as "shipping.crate.acme.com".
That example is not valid, however, according to the spec it appears in. The very next paragraph begins:
Only hosts within the specified domain can set a cookie for a domain and domains must have at least two (2) or three (3) periods in them to prevent domains of the form: ".com", ".edu", and "va.us".
And that indicates that "acme.com" is not a valid cookie domain attribute.
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
Re^2: Warn people who have perlmonks in a URL?
by Aristotle (Chancellor) on Nov 09, 2003 at 10:49 UTC
|
However, doesn't Apache have a feature that will fix this, by rewriting the URI to have a certain machine name?
That won't help if you don't do tell the client to go to a different URL - it's the user agent which decides which cookies to send along with a request to what host.
Makeshifts last the longest.
| [reply] |