Asbjørn Ulsberg wrote:
[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.
Your auth token here seems to me to be equivalent to a session cookie.
If you change the "Authorization" header in Response 2 to "Set-Cookie"
(and make some syntactic adjustments) then this doesn't require any
changes to how deployed apps handle sessions today.