cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1663
Views
4
Helpful
5
Replies

APIC-EM Service Ticket Token Refresh

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


1 Accepted Solution

Accepted Solutions

aradford
Cisco Employee
Cisco Employee

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

View solution in original post

5 Replies 5

aradford
Cisco Employee
Cisco Employee

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

Nathan Sowatskey
Cisco Employee
Cisco Employee

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

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>

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"

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