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/