CODEWITHSUNDEEP
iosresttoken
Thomas Clayson
Thomas Clayson

Reputation: 29925

How to handle API token expiry

Our API returns a user auth code which has a session expiry (30 mins of inactivity). So, if we make an API call using the auth token it renews the session to 30 mins from the time of the call.

After 30 mins of inactivity the API returns an error saying that the token has expired. At this point we should request a new auth token.

However, the obvious way to do this (show the user the log in screen and get them to log in again) will mean cutting the user off in the middle of some functions in the app.

For instance, we have various view controllers with options and inputs which aggregate and submit one whole API call at the end of the process. If the session expires on the server whilst the user is filling out these inputs and views then they will be logged out when the API call is made, and they will lose their progress in these views.

There are two possible workarounds for this:

  1. We set timers in the app ourself to make sure the user is logged out after 30 mins inactivity in the app. This means that they won't get logged out during a set of inputs, however this poses the issues that: the server API may still expire even though we are running our own timer. This won't work therefore.

  2. We poll every 10 seconds or so to the server to ask if the API auth token is still valid. This will eat battery, data and all sorts and just isn't a reasonable way to do something like this.

Does anyone have any ideas?

Upvotes: 1

Views: 1016

Answers (1)

Jeffery Thomas
Jeffery Thomas

Reputation: 42588

From your description, it sounds like a classic failed transaction problem. Just in case you are not familiar with transaction processing, "Nuts and Bolts of Transaction Processing" is a primer on the topic.

If you have the ability to modify the back end system, you will want to ensure an ACID backend.

This could mean building up data on the client and not send the data to the server until you have a complete transaction. That way, if the session times out, the client still has all the data needed to complete the transaction. (leverage atomicity)

This could mean having a transaction token. As a new session is created the client could send the server the transaction token and the state of the transaction is restored within the new session. (leverage durability)

To me both of these options are better than wiping out the existing transaction and forcing the user to start over again.

Hope that helps.

Upvotes: 1

Related Questions