Did AP.context.getToken just solve the issue with expired JWTs?

Correct me if I am wrong, but I believe AP.context.getToken just solved the issue with expired JWTs.

In the past, there was no way to refresh an expired JWT from client-side code. Once it was expired, the user was forced to refresh the page. As a developer, I always thought that this kind of sucks from a UX point of view because either you trouble the user and ask him to refresh the page (e.g. via a Flag :face_with_raised_eyebrow:) or you fail silently leaving the user confused on why things are not working.

I saw a couple of solutions trying to mitigate this problem. E.g. a background task that periodically asks the server for a new token and/or including a new token in each Ajax response that is then stored on the client for the next request.

Yesterday, I happen to watch this video on cachable iframes from Atlas Camp where I came across AP.context.getToken. This allows developers to retrieve a valid JWT from the host product and use it to make Ajax requests to our app server. As an added benefit, the JWT will pass the current context to the app server as part of the JWT. If your request doesn’t take more than 15 mins (JWT expiry) :laughing: you should never see failed request because of expired JWTs anymore.

Does anyone see a reason why not to wrap all Ajax calls in AP.context.getToken?

3 Likes

Indeed it looks to solve this problem once and for all. Moreover as I asked the presenter after the talk the AP.context.getToken() will refresh the token if it has expired and bring you the fresh valid one.

Yes exactly, that’s correct, thanks for highlighting this point. I am surprised Atlassian has not announced this feature bigger, it solves quite a fundamental issue with Atlassian Connect.

Also, the Javascript API docs are still missing documentation of this feature.

It is however documented on Cacheable app iframes

1 Like