Sending AXL requests with End User credentials

Version 1
    This document was generated from CDN thread

    Created by: MIKE WILCOX on 29-05-2009 12:14:23 AM
    Working in I find that if I send an AXL request using the credentials of an End User (part of CCM Super Users and has AXL API permissions) the request is rejected with:
    <html><head><title>Apache Tomcat/5.5.17 - Error report</title><style><!--H1 {fon
    t-family:Tahoma,Arial,sans-serif;color:white;background-color kiss 525D76;font-size:
    22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color kiss 525
    D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;backgro
    und-color kiss 525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;col
    or:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:w
    hite;background-color kiss 525D76;} P {font-family:Tahoma,Arial,sans-serif;backgroun
    d:white;color:black;font-size:12px;}A {color : black;} {color : black;}HR
    {color : #525D76;}--></style> </head><body><h1>HTTP Status 401 - </h1><HR size="
    1" noshade="noshade"><b>type</b> Status report<b>message</b> <u></u></
    p><b>description</b> <u>This request requires HTTP authentication ().</u>
    <HR size="1" noshade="noshade"><h3>Apache Tomcat/5.5.17</h3></body></html>
    But when I send the request with the credentials of an Application User the request is successful.
    Am I supposed to be able to use End User accounts to send AXL requests assuming they have proper permissions in CUCM?

    Subject: RE: Sending AXL requests with End User credentials
    Replied by: David Staudt on 29-05-2009 03:41:30 AM
    Just tried this on CM6.0(1) and 7.0(1) with no problem.  The error message suggests that the Authorization: header could be missing from the request..?

    Subject: RE: Sending AXL requests with End User credentials
    Replied by: MIKE WILCOX on 29-05-2009 04:13:29 AM
    I tried on 6.1(2) and 7.1(2) (beta) and it failed on both. The only difference between success and failure is the username:password string. Same behavior on both clusters.
    Are their any characters in that string that could cause problems? We enforce strong passwords so special characters are required.