Hi,
I'd like to test the Alteryx Gallery API in order to trigger workflows remotely. Unfortunately, I'm unable to connect to the API - both using the interactive API documentation on the server and using Postman.
I am using API Key and Secret from my account settings page. In the Admin console, API access is enabled for my user and my private studio.
The response is always a 401 error:
{
"data": null,
"exceptionName": "UnauthorizedException",
"innerExceptionMessage": "",
"message": "The provided signature(oauth_signature) is invalid."
}
The Request URI looks like this:
https://<Gallery Server>:443/gallery/api/v1/workflows/subscription/?sortField=name&direction=asc&offset=1&limit=10&packageType=1&oauth_timestamp=1548842017&oauth_signature_method=HMAC-SHA1&oauth_consumer_key=<removed>&oauth_version=1.0&oauth_nonce=TPrTJ&oauth_signature=OjENMgFp9o<truncated>
Any idea where to fix this issue? I assume it's not a bug with the interactive API documentation.
Best
Christopher
Are you sure you're using the right API key and secret? When you log into your server gallery, under Settings->Keys the Private Studio API
@DavidP Yes, that's the key and secret I'm using. After triple checking, I got the interactive API doc to work (copy-pasted a space after the secret a couple of times). But Postman still gives me the same error message.
Hi @chrisha,
Calling the Alteryx API from postman or other environments is a little bit trickier as you have to generate the oauth authntication strings yourself. Have a look at this post from @patrick_digan that explains in more detail how to do it.
Also, there is a very helpful blog post by Andre de Vries from The Information Lab, describing how he's built a Java script App that calls the Alteryx API to execute a workflow.
https://www.theinformationlab.co.uk/2017/12/21/use-alteryx-gallery-api-embed-apps-workflows/
I suspect the issue is with the base URL and SSL configuration. The base URL and protocol are part of the OAuth signature. This problem can occur if the base address the server thinks it's called (including port and/or protocol) doesn't correspond the the base address used in the client request. The signatures generated on both the server and client must match, and the base url/port/protocol are used in the signature generation.
If you have a test/beta server, I would review the "Base Address" setting in System Settings, and test modifying the Base Address, testing without any port reference, using machine name vs DNS, or with/without SSL. The interactive docs should then be called through the browser with the same address as the base address. The interactive docs should work when the base URL is configured correctly in System Settings.
If you only have a production server where it would not be practical to test base address configuration changes, I would instead test using the prebuilt javascript client (downloadable from the top portion of the interactive api docs page). You can modify the script to generate the signature with a different base address than what you're actually calling. This should allow you to quickly test the variations.
Most likely it is the inclusion of the port in the base address, SSL termination off-machine, an intermediate proxy, or a discrepancy between DNS vs machine name that is causing the server to generate a signature that differs from the signature your client generated.
Thanks @DanH ,
This was a really useful response as we've been experiencing issues since putting our Alteryx Server behind a load balancer for SSL Termination on AWS.
We've now built an Alteryx API proxy in node.js in a small docker container that handles the OAuth signature calculation for the end users. So our community can hit our API providing their own subscription keys and not need to worry about the sig calculation side, which we calculate in proxy using the http version of the URL being requested prior to hitting the Gallery API on the secure https. It's working well and also allows us to deal with the occasional invalid signature that still seems to randomly occur (possibly times related) as we handle retries in our proxy.
Steve.
Dan H-
Thank you for this tidbit. This was exactly my issue working withe the API. We use SSL and I was using https://myserver.mycompany.com:443/gallery as my base connection. I had to change it to https://myserver.mycompany.com/gallery and after the encryption happened, I used a formula to append the :443 to the url. I struggled with this for days.
Matt
Hi @camanoe,
I'm getting same issue and I'm trying to follow your comments but I'm stuck with it.
Could you please share an example of how you resolved the issue by adding the ':443' after the encryption?
Many thanks in advance.
Regards,
Alberto
Hi Alberto,
The way I handled this was in the macro, just about the last step before the macro finished, I added a formula with Replace([Full_Request_URL], '.org', '.org:443'). This was after the encryption had completed.
Matt
It looks like I have two usernames......