Hi Guys!
Been working on a few bits with extracting orders from XML to inject into the API for our new MIS.
I have all the data read in as metadata and so can reference it to use for the HTTP requests.
The API uses some weird auth method - where you pass username and password as parameters which then returns a token which is valid for 4 hours or so. The token is passed back as the username (no password) using the standard auth method.
Any ideas how can I achieve this?
Off the back of this - does anyone know of any freelance Switch devs that would be up for a bit of work? Had a look in all the usual places but can't see anything helpful!
TIA!
API auth token
Re: API auth token
You can try this app instead of the HTTP Request.
https://www.enfocus.com/en/appstore/product/run-command
The problem with HTTP Request and tokens is that you need to run two calls to the server you want to reach, HTTP Request has problems with that.
https://www.enfocus.com/en/appstore/product/run-command
The problem with HTTP Request and tokens is that you need to run two calls to the server you want to reach, HTTP Request has problems with that.
Re: API auth token
Sorry for the ignorance - how would that help? From what I understand that app looks like it's just a tool for running command/shell stuff?
Re: API auth token
Yes it is a command line tool and you have to write a Shell script or a BAT file that do the talk with the server you want to connect to.
I have used it for connection to an MIS where HTTP Request didn't work.
You can use Postman to play around with to get the syntax you need to connect correctly
I have used it for connection to an MIS where HTTP Request didn't work.
You can use Postman to play around with to get the syntax you need to connect correctly
Re: API auth token
This is not weird. Lots of APIs use such a two-step method, Incidentally, the Switch REST API does exactly the same thing. Next to the method that Jan describes you can also chain 2 HTTP requests, the first one where you get the token and the second one that uses the token. You may need a third one at the end of the flow to log out/revoke the token.The API uses some weird auth method - where you pass username and password as parameters which then returns a token which is valid for 4 hours or so. The token is passed back as the username (no password) using the standard auth method.
A Switch script/app that communicates with the MIS is of course the cleanest and least verbose option. Which one is it (if you are willing to share this of course)?
Re: API auth token
Hi freddyp,
Thanks for your response.
Yes after looking into it a bit more this does seem standard - just seemed like an odd way to go about it on first look.
We are in the process of switching over to Tharstern - they done have an app unfortunately.
If I ran with your suggested method I would need to re-auth for every single switch job right? Is there any problems that could cause do you know?
Thanks again for the help - it's very much appreciated!
Thanks for your response.
Yes after looking into it a bit more this does seem standard - just seemed like an odd way to go about it on first look.
We are in the process of switching over to Tharstern - they done have an app unfortunately.
If I ran with your suggested method I would need to re-auth for every single switch job right? Is there any problems that could cause do you know?
Thanks again for the help - it's very much appreciated!
Re: API auth token
Re-authenticating is done all the time. It is not a problem. This is also an area where an app can offer lots of benefits because it can remember the token and reuse it for as long as it is valid and then request a new one.
Two more considerations.
Check if there is a limit to the number of active tokens. If there is, you will have to make sure to log out as well every time. In our integrations with Salesforce for example we never log out and simply let the token expire. I think of another integration where every user gets a maximum of 10 session ids as they are called there, so logging out is vital.
You may have to limit the number of concurrent requests to the API. I have seen APIs return errors when there are 12 Switch jobs running at the same time communicating with the AP, but working robustly when the requests are serialized.
We have quite a few common customers with Tharstern, so an app would make sense. Warm them up to the idea
.
Two more considerations.
Check if there is a limit to the number of active tokens. If there is, you will have to make sure to log out as well every time. In our integrations with Salesforce for example we never log out and simply let the token expire. I think of another integration where every user gets a maximum of 10 session ids as they are called there, so logging out is vital.
You may have to limit the number of concurrent requests to the API. I have seen APIs return errors when there are 12 Switch jobs running at the same time communicating with the AP, but working robustly when the requests are serialized.
We have quite a few common customers with Tharstern, so an app would make sense. Warm them up to the idea
.Re: API auth token
Brilliant - thank you!!
I suspect whoever the first person who asks Tharstern to build the app will have to foot the integration bill... I did ask if they had one and their response was more or less "why - you have an API?".
I think we are getting there with this... So should I be okay to use the HTTP app in Switch for this?
I suspect whoever the first person who asks Tharstern to build the app will have to foot the integration bill... I did ask if they had one and their response was more or less "why - you have an API?".
I think we are getting there with this... So should I be okay to use the HTTP app in Switch for this?