community
cancel
Showing results for 
Search instead for 
Did you mean: 

Dev Space

Customize & extend the power of Alteryx. SDKs, APIs, custom tools, and more!
Community v19.6

Looks aren't everything... But the latest Community refresh looks darn good!

Learn More
SOLVED

Need support on API call

Asteroid

I am using the Alteryx API client to trigger a workflow execution.

 

I am facing a unique problem related to oauth_signature

 

Normally 60% of the API calls return success on the first time call. But some of them fail and return UnauthorizedException  error with “The provided signature(oauth_signature) is invalid”

 

Response HTTP Code: 401
Response Message: {"data":null,"exceptionName":"UnauthorizedException","innerExceptionMessage":"","message":"The provided signature(oauth_signature) is invalid."}

 

If I re-execute the call within a second or two, it would run successfully. But there are 5% of the calls which would fail on second call as well with the same error returned.

 

Want to understand what could be the reason as the oauth signature generation code is same every time with change in Nonce and Timestamp.

 

The API client is written in JAVA 8.

 

Alteryx-api.JPG

Asteroid

Anyone able to help or to give some advise on this? 

I did some API work with Python a month ago.  I remember having a lot of trouble getting the oauth signature correct.  Your issue is interesting because it's not consistent.  Is there a chance the sort order of your oauth params is unstable?  If the sort order of the params before you generate the signature is inconsistent, it can cause one iteration to pass (when the sort order is correct) and another to fail (when the sort order is wrong), even with the same values.

 

These are the steps I take in my Python script:

  1. Generate list of oauth params (I use a dictionary with string keys and string values)
  2. Sort dictionary of oauth params on the keys (Python has an ordered dictionary type...not sure if Java has something similar)
  3. URL encode sorted params
  4. Generate the base string
  5. Generate the signature using the base string and the secret

 

I hope that helps to give you some ideas of where to look.  It's a bit challenging to say much more without looking at the code.

If you want to look at my code, it is available on GitHub.  I use it (or rather, will use it) to deploy workflows to our gallery.  The link below contains all of the code that deals with interacting with the API.

 

SaveToGallery.py

Alteryx
Alteryx

Hi @AndrewCrayford ,

looks the same like an issue I was fighting with couple of weeks ago. I found that the problem was in special characters within oauth_signature that were probably not correctly url-encoded.

I ended up with sending  oauth_signature in payload.

Comet

@AndrewCrayford- I agree with @PetrT , this is likely due to how the signature is being encoded. I had the same issue last year with the tool that was doing the encoding for us, and I ended up switching to use Python 'requests' library to manage the payload for each request (e.g. this solution on github). I don't know Java, but I'd recommend finding something similar to manage the REST calls if you can.

 

For what it is worth, I'll add the table that I sent to the owner of the tool to demonstrate what was happening for us:

 

oauth_signature

Contents

Result

/5+oCGna797ruxEThKMUJB8C2cA=

all three non-alphanumeric

unsuccessful

yWneEIQ3b3F753X9bWZYFi3HRL4=

equal only

successful

c589p1HIkgqRoBSg+ctlmdHJoLY=

plus and equal

unsuccessful

3831oTL4eK5FUZim96GehpofKmg=

equal only

successful

+69xlGfnoqkzB2hAfuVneq8Bn40=

plus and equal

unsuccessful

T9CHexeA2hBfRZcv+sI+j7ln7Yw=

plus and equal

unsuccessful

nr0c+4h36FvJsn8u3OBxMi4G9bM=

plus and equal

unsuccessful

rpT3unnaiX/WCe7s6lKPsiq13D0=

back slash and equal

successful

YQVuEB/J0rpuVofW24mETbpRt6A=

back slash and equal

successful

i5BEQe0GhvfY/GWjaFRdXXKD3Tw=

back slash and equal

successful

 

You can see that I was able to pinpoint the '+' char was causing issues with the URL encoding.

Asteroid

Thanks @c2willis for the solution. We did a close look at the logs for the signature generated and found that whenever the call has failed, the signature had plus (+) character in it. We did a check if the signature contains the + character, we would regenerate the signature and it would work always.