Problem with basic authentication in a HTTP target extension | Community
Skip to main content

Problem with basic authentication in a HTTP target extension

  • June 9, 2020
  • 4 replies
  • 0 views

I've created an HTTP target extension with the following details:

URL: https://{my_zendesk_instance}.zendesk.com/api/v2/tickets/{{ticket.id}}.json?ticket[status]=deleted

Method: PUT

Content type: JSON

Basic auth: Enabled

Username: myemail@address.com/token

Password: My API token

 

Now the first time I set it to test target and hit submit it works just fine, and I get a HTTP/1.1 200 OK response.

The problem is, once I create the HTTP target, and go back into it and try and test it again, I get HTTP/1.1 401 Unauthorized.

 

When I look at the request headers, the Authorization header is different for both requests. The second failing request's decoded auth header doesn't contain a password, just the username. The first successful request's auth header contains both a username and password.

The real problem is that when I run this extension in an automation, it's failing, and I suspect it's failing because it's messing up the authorisation and not sending the password properly, however there is no way to know.

 

Any idea's on how to solve this? I'm 100% sure it's a bug, but Zendesk has no bug reporting system.

 

 

4 replies

  • June 19, 2020

Hey Jai 👋

I see it more a security measurement.

The reason if you (or more importantly another Admin) went to go back to the target another time, it uses the authentication that is in the password field. And doesn't expose the real API token.
Which is just ******** (not a valid API token, that is stored server side with Zendesk).
Else you would be able to get a secure API token with some easy DOM inspecting and changing.

Rest assured, if you test in the first time it works. Then save it.
If you need test again, you'll need to create a new token.

- Kay


  • August 7, 2020

I am having this exact same issue after updating the token on a HTTP target that was working just fine previously.  Test, it works, update, then it doesn't.  I have also verified with the other program, that upon TEST, the payload is reaching it's target.  Once updated, the information doesn't pass to the target, via test or in the actual situation I need it to work. 

What was said above, make sense, however, based on that, it would also be assumed that the token would pass and the payload would reach it's target in the live situation after it was updated.  It's not, and from what I'm seeing with Jai, it's not working there either.

Again, this is something new on an HTTP target that was previously working, all I did was update the token/password (and yes, this is correct).  I have raised a ticket with Zendesk on this, but any other suggestions would be appreciated.


  • August 17, 2020

Hey Michael,

We are so sorry that we have not gotten back to you here, and are so grateful for your patience in this extraordinary business climate!

I can see you have raised a ticket about this inquiry internally and the ticket has now been solved. If you have additional questions, I would suggest to please follow-up there or you can share more details here. :)


  • March 2, 2021

Erika,

  Can you please suggest the solution recommended over the ticket ?