Hi there @gabriel1,
As I believe you were hit by:
Theoretically, the current implementation sets unused-token invalidation to 90 days, not 30. But My users were experiencing more frequent problems anyhow.
In my case, the problem is more complex due to the nature of the plugin. My users are allowed to place as many macros on a single Confluence page as they wish. This creates a scenario in which a single Confluence page refresh can create 50 requests to my backend.
If a user has a valid access_token it is all fine. I can just use it. But access tokens are valid only for one hour. So it is normal that my backend receives 50 parallel requests with an expired access token. In this scenario, I am trying to refresh all the tokens in parallel. Due to the nature of iframe loads, this can create a race condition:
- User open page with three macros after one hour of inactivity
- Backend receives 3 parallel requests and attempts to use refresh token
"A"to refresh both access token and refresh token. All refresh attempts are using the same refresh token ("A") - Request number 1 is the first and replaces refresh token
"A"with"B" - Request number 2 is the second and replaces refresh token
"A"with"C"(this is allowed within 10 minutes windows) - Request number 3 is delayed and attempts to use token
"A"while token"C"was already issued - I receive my favorite: “Unknown or invalid refresh token”
I implemented an update to my token handling code that handles “Unknown or invalid refresh token”:
If my request to requestAccessToken returns invalid_grant I am pulling fresh user info (with both access and refresh tokens) from the database cache. It is possible that I already have a newer token ("C" from example above) and I should use the access token I obtained in a different thread and ignore this error