At 17:49 08/11/2007, Tomasz Zieleniewski wrote:

Hi Piotr:)

RFC only implies that proxy should not challenge the ACK message and moreover it says that client sending ACK should duplicate Authorization and Proxy-Authorization headers. This it what my client does. But according to the description of the proxy_authorize function it only verifies that credentials are valid. This function doesn't cause the challenge response to be sent to the client. This is performed with the usage of proxy_challenge function. "The function verifies credentials according to RFC2617. If the credentials are verified successfully then the function will succeed and mark the credentials as authorized (marked credentials can be later used by some other functions). If the function was unable to verify the credentials for some reason then it will fail and the script should call proxy_challenge which will challenge the user again." In my opinion, that is why proxy_authorize function should generate the uid avp for ACK request if verification of credential gives positive result.

Well -- it should be stored somewhere in transaction state and someway I guess you should be able to get access to it (not sure if with or without some hack) ... but do you relaly need that? ACK has a transport function and as such, I don't see the use value for doing more processing with it than abosrbing/forwarding...

-jiri

-- Jiri Kuthan http://iptel.org/~jiri/