On Wed, 2008-12-10 at 13:35 -0500, Dale Worley wrote:
> I'm starting the design discussion on XECS-1983 ("Re-SUBSCRIBE to status
> server fails."). The symptoms are blocking various QA tests, so we want
> to get this straightened out promptly.
>
> The underlying bug is that various components use the method
> HttpMessage::getDigestAuthorizationData to extract the authorization
> header values, one-by-one (as specified by an integer argument,
> 'index'). The method seems to be intended to extract the Authorization
> and Proxy-Authorization values together on an equal basis. But what the
> code does is attempt to extract the index-th value from the
> Proxy-Authoriztion header(s), and if there is no such, it attempts to
> extract the index-th value from the Authorization header(s). This only
> works correctly if the message does not contain both a
> Proxy-Authorization and an Authorization header.
>
> The general nature of the fix is obvious: Fix
> getDigestAuthorizationData to return the proper values even if there is
> both an Authorization and a Proxy-Authorization header.
>
> However, there are two design alternatives:
>
> 1. Not distinguish between Authorization and Proxy-Authorization,
> effectively concatenating their values into one set. This appears to be
> the intention of the current code. This approach will almost certainly
> not cause problems with the calling applications, as the applications
> are supposed to search through all values and respond only to ones that
> are valid.
>
> 2. Distinguish between Authorization and Proxy-Authorization by
> splitting the method into two (or using an indicator argument). This
> requires that every calling application decide whether it examines
> Authorization or Proxy-Authorization headers. (The SIP architecture
> assumes that UAs use the former and proxies use the latter.) This can
> lead to a UA being demanded for authentication more than once (once for
> proxies and once for UAs), but it appears that existing UAs handle this
> correctly.
Since any given component should only look at the authorization
information that it challenged for, and since each knows whether it sent
a 401 (user agent) or 407 (proxy) challenge, I think that #2 is the
right way to go.
Rather than add an argument, make 2 methods:
getUserAgentAuthorizationData and getProxyAuthorizationData (I suspect
you'll find it easiest to have a private method that has lots of common
code under the covers).
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
