[thelist] Cookies and Session state for Authentication
Andrew Clover
and-evolt at doxdesk.com
Fri May 14 02:45:17 CDT 2004
Mike Pouncy <pouncy_1 at hotmail.com> wrote:
> I am trying to build an authenication system that works for the
> largest possible group of users/browsers
HTTP Basic Authentication (triggered by the 401 response code and
WWW-Authenticate header) is a required part of the HTTP spec and is
supported by absolutely all browsers.
If Basic Authentication meets your needs it is definitely the best way
to do auth - that's what it was designed for. Using cookies/sessions
instead is a hack which is sometimes used to get around the limitations
of Basic Auth (and just as often used because the authors just don't
know about Basic Auth).
Limitations are:
- the username/password is sent by the browser unencrypted.
HTTP Digest Authentication gets around this but is not widely
supported; if security is a requirement then encrypting the
entire session (including username/password) using SSL is the
best plan.
- Basic Auth cannot be controlled from JavaScript. In a way this
is a benefit for security as the login details are not vulnerable
to theft through cross-site-scripting in the same way cookies are.
However it means you can't manually log the user out or present
a customised login page (you always get the browser's own auth
prompt).
- cross-server support can be tricky. In IIS you have to turn off
all authentication methods except 'anonymous access', and remove
custom error pages for 401 errors, to prevent IIS from getting in
your way. (NB: I don't know if this is still the case for ASP.NET.
You may also be able to use one of many ISAPI authentication filters
to do the task for you.) In Apache you have to recompile with a
flag set for it to pass auth information to CGI scripts.
It is possible to use a cookie-based auth scheme with basic auth as
backup, but it's a bit of work.
--
Andrew Clover
mailto:and at doxdesk.com
http://www.doxdesk.com/
More information about the thelist
mailing list