The point that should be taken is that if one must use a cookie for auth,
expire it early and often. What would _really_ be nice is if there were
a javascript or ecmascribble or whatever it's called object that can _set_
or _unset_ the auth request headers so one _could_ do a form driven
authentication that used HTTP standards (basic and digest authentication).
Well, it'd be nice if browsers did a lot of things, like sent a
useful header:
Accept-code: ecmascribble/1.4, JVM/1.2, client-side-perl/6.0
...the percentage of sites that actually use content negotiation is
probably < 5% yet the browsers send all this chatter about what they
accept for content and nothing about programmatic capabilities. Fooey.
But I digress. Go ahead, use cookies and mangle them into auth headers
but make sure they aren't persistent cookies. And don't use this level of
security for banking or commerce; those get mangled URL paths. In a self
contained intranet world, using client certificates and mod_ssl sounds
like a good proposition.
-Ian
Meanwhile, back at the ranch...
> Jeffrey> Cookies are an acceptable way to make the browser remember
> Jeffrey> something about your site.
> Be careful when you use cookies. Make sure it's your LAST choice.
> Mangled URLs and hidden fields are other straightforward alternatives.
--
Salon Internet http://www.salon.com/
HTTP mechanic, Perl diver, Mebwaster, Some of the above
Ian Kallen <[EMAIL PROTECTED]> / AIM: iankallen / Fax: (415) 354-3326
