On Tue, 2008-12-16 at 17:01 +0000, Scott Lawrence wrote:
> On Tue, 2008-12-16 at 11:28 -0500, Dale Worley wrote:
>
> > It sounds like the correct solution is to have two levels of functions:
> >
> > One function(s) is the current get-authorization-info function, which
> > extracts a specified value from the specified type of header.
>
> Agreed (sort of... see below)
>
> > The other function(s) should encapsulate "how a proxy (or server) tests
> > the authentication/authorization of a message", and would take into
> > account sipX's equivalence of the three headers. (This has the
> > advantage that we can factor out all that code in all the components,
> > and ensure that they work consistently.)
>
> I don't think that it's quite right to think of it as "sipX's
> equivalence of the three headers"; they are not equivalent. A proxy
> should never use an Authorization header and a UA should never use a
> Proxy-Authorization header. Yes, I'm being a bit of a purist, but I'm
> just sure that if we blur this line that it will eventually come back to
> bite us.
The difficulty is that we're already being bitten by doing the right
thing. In particular, we're trying to design around the fact that
certain popular phones won't correctly handle the case where a request
receives a 407 challenge and then a 401 challenge. One solution would
be to have UAs accept Proxy-Authenticate headers. But that has the
architectural problem you mention. Another solution would be to have
UAs accept P-Asserted-Identity as an alternative to Authenticate, but
that only works if proxies *always* add a P-A-I to any request for which
they have prompted for a Proxy-Authenticate. But I don't know if the
proxy does that, or if we've previously considered that a functional
requirement.
> > Can we nicely encapsulate all that logic so as to build the second
> > function?
>
> Well, if we're going to try to come up with the "right" solution (worth
> discussing, certainly)...
>
> I think that HttpMessage (and therefor SipMessage) should provide two
> methods:
>
> getAuthorizationHeader
> that iterates over values of the Authorization header
> for use by user agents.
>
> getProxyAuthorizationHeader
> that iterates over values of the Proxy-Authorization
> header for use by proxies.
Currently, we have one method that does both (via a binary argument).
Maybe that isn't the best way to do it, but I implemented as you spec'ed
it in rev. 11420, and as you modified all of its callers to expect. In
any case, it doesn't make a great deal of difference.
> then something in sipXcommserverLib should provide higher level methods
> that add the handling of a sipXecs PAI header on top of those:
>
> getAuthorization
> For user agents.
>
> getProxyAuthorization
> For proxies.
>
> These are also iterators, that return true/false to indicate if a "next"
> identity is returned. Each should look first for a PAI header with a
> valid sipXecs signature; if that is found, it's the only identity this
> method will return. If no PAI is present, then they revert to iterating
> over the appropriate header above.
IMHO, I think it would be useful to make a non-iterator function (or
functions) that encapsulate all the logic for looking for authorization
and deciding whether a challenge needs to be done. Partly this is
because the iterator-style get{,Proxy}Authorization you propose is
painful to implement, but also because (I think) all the components use
essentially the same logic for examining authorization values, etc.
There's no point in duplicating that a dozen times, especially since
some of the duplications will be wrong.
Dale
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
