Emiliano <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]
...
> > I fixed this by sending a Set-Cookie:
> > header in which I reset the expiration date to a date in the past. This
gave
> > me the desired results. Since I had to read the source to find out how
the
> > cookie is set (Netscape is very precise about receiving the exact cookie
> > information), it may be a good idea to add a function that does the
same,
> > mgd_auth_midgard_delete(void);.
>
> 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'.
> > Also, I noticed that mgd_auth_midgard
> > 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 '/' .
>
> Don't know much about cookies. If you can tell me what to send I'll make
> sure it gets sent.
All I know comes from this page:
http://www.netscape.com/newsref/std/cookie_spec.html
highlights from the page:
Syntax of the Set-Cookie HTTP Response Header
This is the format a CGI script would use to add to the HTTP headers a new
piece of data which is to be stored by the client for later retrieval.
Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure
NAME=VALUE
This string is a sequence of characters excluding semi-colon, comma and
white space. If there is a need to place such data in the name or value,
some encoding method such as URL style %XX encoding is recommended, though
no encoding is defined or required.
This is the only required attribute on the Set-Cookie header.
expires=DATE
The expires attribute specifies a date string that defines the valid life
time of that cookie. Once the expiration date has been reached, the cookie
will no longer be stored or given out.
The date string is formatted as:
Wdy, DD-Mon-YYYY HH:MM:SS GMT
This is based on RFC 822, RFC 850, RFC 1036, and RFC 1123, with the
variations that the only legal time zone is GMT and the separators between
the elements of the date must be dashes.
expires is an optional attribute. If not specified, the cookie will expire
when the user's session ends.
Note: There is a bug in Netscape Navigator version 1.1 and earlier. Only
cookies whose path attribute is set explicitly to "/" will be properly saved
between sessions if they have an expires attribute.
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".
The default value of domain is the host name of the server which generated
the cookie response.
path=PATH
The path attribute is used to specify the subset of URLs in a domain for
which the cookie is valid. If a cookie has already passed domain matching,
then the pathname component of the URL is compared with the path attribute,
and if there is a match, the cookie is considered valid and is sent along
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.
secure
If a cookie is marked secure, it will only be transmitted if the
communications channel with the host is a secure one. Currently this means
that secure cookies will only be sent to HTTPS (HTTP over SSL) servers.
If secure is not specified, a cookie is considered safe to be sent in the
clear over unsecured channels.
.... and:
If a CGI script wishes to delete a cookie, it can do so by returning a
cookie with the same name, and an expires time which is in the past. The
path and name must match exactly in order for the expiring cookie to replace
the valid cookie. This requirement makes it difficult for anyone but the
originator of a cookie to delete a cookie.
-----------
I suppose that's all the info you need...
Armand.
--
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]
