[Web-SIG] New spec: simple authentication

Ian Bicking ianb at colorstudy.com
Tue Nov 14 18:15:28 CET 2006


Sylvain Hellegouarch wrote:
> Ian,
> 
> 
> 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 mailing list