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.
There are some sipXtackLib methods that use getDigestAuthorizationData:
getAuthorizationUser and verifyMd5Authorization. I haven't gotten to
the bottom of what they do and whether they would be damaged by this
change.
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
