On Wed, 3 May 2000, Armand A. Verstappen wrote:
> > Or we could have mgd_auth_midgard("","",1) delete the cookie. I see no
> > problems with that.
> >
> Sounds even better to me, unless there are users that actually see the
> current behaviour as a 'feature'.
It's a trivial fix, so I'd check it in, but...
> doesn't send the domain with the cookie. I may be wrong, but I think
> this
> could cause problems if I have www.blah.com in sitegroup 1 and
> www.blah.com/sub
> in sitegroup 2, because the path is set to '/' .
True, but if the two hosts are in the same sitegroup you'd have to relogin
between them even though the password would still work. This problem
generalzes to prefix=something and prefix=something/more hosts. Less
trivial to get right. You will not accidently be athenticated when
switching between SGs, btw, since it's unlikely that the username/password
will match.
> 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 in fact creates the same problem. Mixing hosts/subhosts or
prefix/subprefixes in different sitegroups is not likely to work very
intuitively with cookie authentication.
> with the URL request. The path "/foo" would match "/foobar" and
> "/foo/bar.html". The path "/" is the most general path.
> If the path is not specified, it as assumed to be the same path as the
> document being described by the header which contains the cookie.
And the same problem again.
Deleting the cookie is simple, and I'd check it in, but I want more
discussion on the above topics before changing the path in the cookie.
Agreed?
Emile
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
