URL:
<http://gna.org/bugs/?func=detailitem&item_id=6694>
Summary: Attaching cookies to a .domain
Project: Savane
Submitted by: beuc
Submitted on: dimanche 20.08.2006 à 19:29
Category: Web Frontend
Priority: A - Later
Severity: 3 - Normal
Status: Confirmed
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Release:
Planned Release:
_______________________________________________________
Details:
Currently Savane inconsistenly sets cookies with or without attaching it to a
domain. At first I thought this was meaningless, but actually there a
difference:
- without specifying the domain, it's attached to, say, gna.org
- when specifying the domain, it's then attached to *.gna.org
This only works for real domains:
http://wp.netscape.com/newsref/std/cookie_spec.html
---
domain=DOMAIN_NAME
When searching the cookie list for valid cookies, a comparison of the
domain attributes of the cookie is made with the Internet domain name of the
host from which the URL will be fetched. If there is a tail match, then the
cookie will go through path matching to see if it should be sent. "Tail
matching" means that domain attribute is matched against the tail of the
fully qualified domain name of the host. A domain attribute of "acme.com"
would match host names "anvil.acme.com" as well as
"shipping.crate.acme.com".
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". Any domain that fails
within one of the seven special top level domains listed below only require
two periods. Any other domain requires at least three. The seven special top
level domains are: "COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT".
---
This is what triggers the "no cookies for local domains" bug we've had a
couple times on this tracker: it doesn't have enough dots/periods to be taken
into account. This is a kind of feature...
In the general case, the 'domain' parameter of setcookie() is just left over,
which sounds logical (a cookie I get on gnu.org need not be sent to
*.gnu.org). Not using that parameter also fixes the bug I mentioned.
Incidentally it also avoids getting several SV_THEME cookies for a Savane
installation.
But I think that gna.org uses this feature to get the cookie sent to
mail.gna.org and use the perl ::Frontend there. So removing the domain
parameter will bug you.
I still think this should be an exception. Maybe we could introduce a
"cookies domain" parameter, blank by default, and set to e.g. ".gna.org" at
Gna.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?func=detailitem&item_id=6694>
_______________________________________________
Message posté via/par Gna!
http://gna.org/
_______________________________________________
Savane-dev mailing list
[email protected]
https://mail.gna.org/listinfo/savane-dev
