'Unauthorized' getting side conversations from API but successful getting ticket | Community
Skip to main content

'Unauthorized' getting side conversations from API but successful getting ticket

  • September 21, 2022
  • 5 replies
  • 0 views
💾

I am requesting the following URL from the API and getting a valid response with ticket information.
https://onthegotours.zendesk.com/api/v2/tickets/3018.json

However when I request the following URL (using exactly the same code):
https://onthegotours.zendesk.com/api/v2/tickets/3018/side_conversations.json
I get 'unauthorized' as the response.
 
 
We are on the professional plan and the user / token I am using (myself - admin) is able to see the ticket and side conversionations in the Zendesk front-end.
 
Any help / insight would be appreciated.

    5 replies

    Greg29
    • Greg29
    • September 21, 2022
    Hi Ryan! That's a really strange issue you're having and I'd like to see if we can figure out where the problem is. Could you try just making that API call from your browser when you're authenticated into your Zendesk subdomain? That will help determine if the problem is with the authentication that it being sent from your service or somehow with the endpoint from our side.
    💾
    • 💾
    • Author
    • September 21, 2022

    Thanks for your help.

    When I make the request (same URL) via my web browser after logging in to ZenDesk I do get a valid JSON response.  So in that sense the only difference is the method of authentication, session VS token.

    Here is the PHP test code as simple as I can make it. The first succeeds, where the 2nd doesn't.

    $url = "https://onthegotours.zendesk.com/api/v2/tickets/3018.json";
    $data = getFrom($url);

    $url = "https://onthegotours.zendesk.com/api/v2/tickets/3018/side_conversations.json";
    $data = getFrom($url);

    function getFrom($url) {
    $headers = array (
    'Accept: application/json',
    'Content-Type: application/json'
    );

    // Setup query:
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
    curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
    curl_setopt($ch, CURLOPT_USERPWD, Config::zendeskUsername()."/token:".Config::zendeskAPIToken());
    curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'GET');
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

    // Perform query:
    $response = curl_exec($ch);
    return $response;
    }

     

    Greg29
    • Greg29
    • September 21, 2022
    Thanks for sharing that and good news, I figured out the issue!
     
    When I tested this out, I ran into issues with CURLAUTH_ANY the same way that you were, but I was able to successfully make the calls with CURLAUTH_BASIC. To me it seemed that it wasn't actually using "ANY" and instead seemed to be using the CURLAUTH_ANYSAFE method, which specifically does not include basic auth. This made sense to me since basic auth was working and "BASIC" is included in "ANY." I somehow failed to consider that the likelihood of there being an issue with libcurl was far less likely then with their being an issue with our API. To that end... 
     
    After I dug into this a bit further, I discovered that the side conversations API does not return an authentication challenge header upon 401 (www-authenticate), which is actually a requirement of the RFC. As an example, when you make a request to https://onthegotours.zendesk.com/api/v2/tickets/3018.json  without authentication, we return (among others) the following header:
     
    www-authenticate: Basic realm="Web Password"
     
    So when you're making a request using CURLAUTH_ANY, what I believe is happening is that it's expecting to get some sort of response from the server if the first attempt fails so that it knows what to do next. Instead we don't give it anything useful and it just fails silently, so the 401 will be returned for the side conversations request, even if a successful request is made to any other endpoint. 
     
    The solution for now is to use CURLAUTH_BASIC and the requests will complete successfully. I'm going to work with the dev team that owns these APIs to ensure that the responses contain an auth challenge header in the future as well. If that works and it resolves the issue, I'll drop you a line letting you know about this in the future.
     
    Let me know if you have any other questions about this!
      💾
      • 💾
      • Author
      • September 22, 2022

      Thanks for getting back to me with that solution so quickly.  I can confirm that changing the line:

      curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_ANY);

      to

      curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);

      allowed me to get a valid response for both tickets and side conversations. Much appreciated.

       

       

      Greg29
      • Greg29
      • September 23, 2022
      Glad to hear that worked! I also wanted to let you know that our dev team was able to implement a quick fix to resolve this and it's working as expected now! So you could theoretically go back to CRLAUTH_ANY if you wanted to, but there's probably no explicit benefit to doing that.
      Terms & ConditionsCookie settingsAccessibility statement