Hi,
In the light of the discussions we had so far - on various modes of
authentication and session tracking: cookie, cookieless, form-data,
URL-parameter etc etc etc, may I suggest an improvement in HTTP/1.1 -
which, again, is open to discussion.
Currently, associated with HTTP-Authentication are two (or three) headers:
1. WWW-Authenticate
2. Authorize
3. Optionall, Auth-Info
Can we have a header called Auth-ID which may perform the task of a
session-ID. Instead of putting in form-data or part-of-URL (which
leads to a must-form-on-every-request) or as cookies (sometimes
disabled, for good reasons as mentioned in thread), we can have it as
a separate header.
A small flow can be something like this:
1. Server requets authentication (HTTP-Authentication or simply form based)
2. Client Authenicates
3. Server validates authentication and sets a header (Set-Auth-ID:
<some-id>, path='/some/path')
4. Client, when requesting any URL from the server under '/some/path',
a header is passed (Auth-ID: <some-id>).
5. Server makes use of this header to dis/allow any protected content.
Ok... another extension in HTTP/1.1 may not be on cards... but do we
have any other option? Or just live with Cookies? :-(
--
Cheers,
Gaurav Vaish
http://www.mastergaurav.org
http://mastergaurav.blogspot.com
--------------------------------
On 5/12/05, Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
Simple answer ... there is no easy reliable alternative to:
a. cookie
b. Stick it in the request URL and/or data ... many alternatives in the
details
...neither of which are good places to store authentication tokens if exposure
of such tokens would compromise either the resource being accessed
or the user's identity. neither cookies nor URLs are typically well-protected
against accidental exposure. they were not designed to be used for
authentication.
see RFC 2964 for more on use of cookies.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf