[SR-Users] UAC, parsing auth header failed

[Alex Balashov]

On 07/02/2010 03:22 AM, "Ján ONDREJ (SAL)" wrote:

> I use defaults, so looks like I use automatic restore. I don't know, how to
> send it manually, so auto looks to be a good choice. uac_restore_from can't
> be used from reply route.

If you are using the "auto" restore mode, it is not necessary to call 
uac_restore_from().

> Looks like uac_auth() does not send another request. Can somebody give me a
> more complete example, how to use uac_auth()? Do I need to use uac_req_send
> or call some route to do it? May be it is my problem, because second INVITE
> is not sent.

The uac_auth() function is intended to be called from a failure route 
when catching a 407 Proxy Authorization Required challenge.

You will need to use serial forking ("branching") to re-send the 
request with the appropriate digest authentication headers:

I would use it like this:

    route {
       ...
       t_on_failure("MAYBE_AUTH_CHALLENGE");

       if(!t_relay())
          sl_reply_error();
    }

    ...

    failure_route[MAYBE_AUTH_CHALLENGE] {
       if(t_is_canceled())
          exit;

       if(t_check_status("407")) {
          append_branch();

          if(!uac_auth()) {
             xlog("L_ERR", "Something went wrong with uac_auth()!\n");
             t_reply("500", "Internal Server Error");
             return;
          }

          if(!t_relay()) {
              t_reply("500", "Internal Server Error");
              return;
          }
    }

Keep in mind that uac_auth() will silently fail to add the right 
headers, without explanation, if the realm you provide it (whether by 
AVP or via the "credential" modparam to 'uac') does not match the 
realm requested in the challenge from the provider, but you won't know 
that unless you turn up debug verbosity.

-- 
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/