On Tue, 25 Nov 2008 19:54:46 +0100, Julian Reschke <[EMAIL PROTECTED]> wrote:
thanks a lot for this proposal which seems to go into the right
direction.
Indeed. I think this is an area with an enormous potential for improvement and
it's very encouraging to see so many great ideas about the issues involved and
how to solve them.
I didn't yet have time to look into this in detail, but it currently
seems to require the UA to still parse the HTML page. Wouldn't it be
better of the *headers* of the response (such as WW-Authenticate, Link,
...) would contain sufficient information to perform the login without
having to do that; such as a URI to POST to, plus the parameter names
for user name and password?
I agree that more should happen on the HTTP level and with more control given
to the web application. Considering the state of the next version of the HTTP
specification(s), would it perhaps be a good idea to discuss this with the HTTP
WG as well?
'WWW-Authenticate: HTML' or something similar is a step in the right direction.
I don't see it as necessary to identify the form that does the authentication,
though. Just as [1], I think that puts a burden on the user agent that really
isn't necessary.
Web application developers pulls a lot of hair doing web form-based
authentication already and are used to having control over just about every
part of it. Taking that control and responsibility away at this point is only
deterring, imho.
Instead, we should leave the control in the hands of the web application
developers and force as little as possible on to the user agent developers. The
way I see it, the following example should be enough to perform a successful
authentication:
[Request 1]
GET /administration/ HTTP/1.1
[Response 1]
HTTP/1.1 401 Unauthorized
WWW-Authenticate: HTML realm="Administration"
<!DOCTYPE html>
<html>
....
<form action="/login">
<input name="username">
<input type="password" name="password">
<input type="submit">
</form>
</html>
[Request 2]
POST /login HTTP/1.1
username=admin&password=secret
[Response 2]
HTTP/1.1 302 Found
Authorization: HTML QWxhZGRpbjpvcGVuIHNlc2FtZQ== realm="Administration"
Location: /administration/
[Request 3]
GET /administration/ HTTP/1.1
Authorization: HTML QWxhZGRpbjpvcGVuIHNlc2FtZQ== realm="Administration"
[Response 3]
HTTP/1.1 200 OK
<!DOCTYPE html>
<html>
...
<h1>Welcome!</h1>
</html>
The twist here is that it is up to the server to provide the authentication token and
through the 'Authorization' header, give the client a way to authorize future requests. I
append the "realm" parameter to the 'Authorization' header to give the server
and client a way to control authorization and more importantly deauthenticate (e.g.
logout) for different realms on the same web site.
Since more is up to the web application now, a deauthenticate works the
following way:
[Request]
POST /logout HTTP/1.1
[Response]
HTTP/1.1 200 OK
Authorization: HTML realm="Administration"
<!DOCTYPE html>
<html>
...
<h1>Good bye!</h1>
</html>
The empty token in the 'Authorization' header indicates that it should be
forgotten for the given realm by the user agent and that future requests to
resources within the same realm requires a reauthentication.
This suggestion overloads the 'Authorization' header quite a bit, but since
we're inventing a new authentication scheme that the UA needs to understand
anyway, and especially if we get the HTTP WG on board here, I think this can
only give positive effects.
The alternative is to invent a new response header to serve the same purpose, but seeing
as the request and response header -- if 'Authorization' is used -- are identical, a
typical authentication by a browser supporting the "HTML" scheme is just to
opaquely copy+pasting the entire 'Authorization' header from the request to the response.
____
[1] <http://www.w3.org/TR/NOTE-authentform>
--
Asbjørn Ulsberg -=|=- [EMAIL PROTECTED]
«He's a loathsome offensive brute, yet I can't look away»
