10-29-2016 04:04 AM - edited 03-01-2019 04:32 AM
Using POSTMAN, is there a way to automatically refresh the APIC-EM service ticket token periodically and update the token result into the X-Auth-Token field used in other API calls, to avoid doing this manually?
Thanks
Solved! Go to Solution.
10-29-2016 12:05 PM
Hi Christopher,
the first one is hard as you necessarily know when to refresh the token.
My collection on github shows how to auto-populate the "X-Auth-field".
I normally just get one ticket, then run all the requests in a session.
apic-em-samples-aradford/tools/postman at master · CiscoDevNet/apic-em-samples-aradford · GitHub
Adam
10-29-2016 12:05 PM
Hi Christopher,
the first one is hard as you necessarily know when to refresh the token.
My collection on github shows how to auto-populate the "X-Auth-field".
I normally just get one ticket, then run all the requests in a session.
apic-em-samples-aradford/tools/postman at master · CiscoDevNet/apic-em-samples-aradford · GitHub
Adam
11-05-2016 09:09 AM
Christoph
I have a similar question. Note that the discussion below applies to using code clients, not Postman.
As matters stand now, it does not seem to be possible to determine whether a given service ticket is valid. There are, then, two logical options:
- Hope that the service ticket remains valid for as long as is necessary to execute multiple requests in a session
- Obtain a new ticket before every request
The first option is indeterministic, as one can't know how long the processing will take for the requests in a given session. It is perfectly possible that one can write code that works in a test environment with limited data loads, but which fails in production with higher and changing data loads.
So, hoping that the ticket remains valid for as long as it takes is to risk creating a situation that leads to random and hard to replicate errors.
The second option means that you need to make twice as many requests, as each functional request has to be preceded with an authentication request. This increases the load on the server, increases latency for a given logical functional request, and increases the potential for partial failure.
Consequently, the only proper solution here is to check each functional request for exceptions, which one would properly do anyway, and check for session timeout failures as part of the exception/response code handling. In the case of an exception for a session timeout, the code would need to reauthenticate, create a new token, and then re-execute the functional request. This is cumbersome, but unavoidable.
A pseudo-code version is below:
while True:
try:
headers = {'x-auth-token': token, 'content-type': "application/json"}
result = requests.put(url=url, data=json.dumps(payload), headers=headers, verify=verify)
result.raise_for_status()
if result.status_code != 202:
print("Response code is not 202, so no task was created.")
else:
taskId = result.json()['response']['taskId']
task_status = check_task(taskId)
print("Task status is: \n" + json.dumps(task_status, indent=2))
break
except requests.exceptions.HTTPError as e:
print("Exception when making request - " + str(e))
if e.response.status_code == 401:
print("401 exception with request, refreshing token.")
token = get_token()
It would be slightly better if the API did allow for session revalidation, as with the APIC-DC API, so perhaps the APIC-EM API designers might consider that.
Regards
Nathan
11-05-2016 10:14 AM
Thanks Adam - this is very helpful.
Chris
. :|: . :|: . Chris Hobbs | Systems Engineer | Cisco Systems, Inc. | Phone: 703-484-7217<tel:703-484-7217> | Video & Email: chrhobbs@cisco.com<mailto:chrhobbs@cisco.com>
11-06-2016 07:48 PM
Hi Nathan,
when you get a ticket, you also are told the timeouts for that ticket.
{
"response": {
"serviceTicket": "ST-xxxxxxxxxxxxxxx-cas",
"idleTimeout": 1800,
"sessionTimeout": 21600
},
"version": "1.0"
11-07-2016 12:54 AM
Thanks Adam
You do get the relative timeout, but not the absolute timeout. The absolute timeout is the timeout relative to when I get the ticket.
The data structure you show above, from the server, contains some of what I need. To make this work for the absolute timeout, I would need to wrap that data structure in one that also contains the absolute timeout, calculated from the time the data structure was created + the sessionTimeout value. I would also need a mechanism to record how long the token has been idle for.
The typical thing to do is to create a wrapper class that provides an accessor to the token value. The accessor checks the idle and absolute session timeout values, and returns a stored token value, or obtains a new one, transparently.
This is the kind of thing that the uniq library could do (maybe does already). Unfortunately, the uniq library only works with Python 3, which limits its applicability somewhat.
Regards
Nathan
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide