I've written a patch for XECS-1983. It turns out that Scott had done most of the work already in rev. 11420. The code uses "option 2", that is to add a parameter to all of the sipXtack methods that extract Authorization/Proxy-Authorization header information to select which type of header to examine.
I've also added a unit test to check some of these behaviors. The code now builds and passes the unit tests; I hope to test the system in operation tomorrow morning. On Wed, 2008-12-10 at 20:07 +0000, Scott Lawrence wrote: > Like I said on the list, I'd prefer to have seen two public methods > rather than a switch, but it will do for now. > > While you're in there, I'd also make a couple of other changes to that > method for robustness: > > * Move the remove(0) on each of the output arguments up to right > at the beginning so that they don't have anything in them if the > function doesn't return true (I suppose there is _some_ chance > this will break something, so skip it if you want to do the > minimal thing). I've made this change. The methods are inconsistent about whether output string variables get empties if the method is unsuccessful, so there is no design violation if we put the remove(0)'s at the top of the method. > * Add an explicit flag for the return code that is only set to > true if the required params are found in the header value - as > written now, this would return true: > Authorization: bogus This makes sense, but doesn't work -- all of the callers use the return value to determine whether to increment the index and call the method again. So even the most bogus Authorization header has to cause the method to return true. (This doesn't cause a problem because the caller will not validate the returned data values.) But I've documented the behavior in HttpMessage.h. 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
