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.
> 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.
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.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
