[Web-SIG] New spec: simple authentication
ianb at colorstudy.com
Tue Nov 14 18:15:28 CET 2006
Sylvain Hellegouarch wrote:
> Why disallowing the application to set the WWW-Authenticate header? If a
> middleware is present it will be overwritten anyway. If no middleware is
> there then at least you won't break the first MUST in section 10.4.2 of
> RFC 2616.
I suppose there's no problem with it; though of course if you response
with "WWW-Authenticate: Basic" and then don't have enough information to
handle the response, you don't be doing anything useful.
"WWW-Authenticate: x-internal-wsgi" would be... well, explicit at least ;)
> What happens if part of my application is to be protected by OpenID,
> another by Digest and a third one by a in-house auth scheme? How does your
> spec. deal with this?
You'd have to lay out and configure your middleware appropriately.
Though I can imagine a problem where you have Digest in a specific area
with OpenID everywhere else; the OpenID would catch the Digest response
and rewrite it.
I guess there might be some purpose to the WWW-Authenticate header there
too. You could say that a 401 response with a x-internal-wsgi
authentication type (or a missing WWW-Authenticate header) should be
handled by middleware; other responses should be ignored. This is also
useful for WebDAV areas, which probably live in a subdirectory somewhere
and have more limited client authentication support.
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Web-SIG