What's the correct way to handle expired access token

[cjacky475]

Hello, after user authenticates via OAuth2 I request refresh token, which I store on user's mobile device. Now to perform various actions (upload/download) from the user's Dropbox storage, I build:

DbxClientV2(config, credentials)

As I was reading this post https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/Is-it-possible-to-get-a-permanent-token... it was mentioned that "The SDK will automatically catch expired access token errors and call the API to get a new short-lived access token when needed." What's the correct way for me to catch whether API was called to receive new access token or what would be the best practice to get the new access token and store it for further calls until it expires? Or do I need to do this manually in try { } catch { } or by checking the expiration date of the access token and then call: 

client.refreshAccessToken()

Thanks.

[Здравко]

---

@cjacky475 wrote:

... "The SDK will automatically catch expired access token errors and call the API to get a new short-lived access token when needed." ... Or do I need to do this manually in try { } catch { } or by checking the expiration date of the access token and then ...

---

Hi @cjacky475,

😁You give correct answer to you own question actually. You don't need to handle anything to refresh access token, since SDKs do it internally. Even more: there's nothing to catch! So using try-catch is not applicable. All SDKs check expiration status and do refresh without need error to happen, so in any try-catch you gonna catch nothing such. 😉 While particular client object has been initialized correctly and works, you don't need to care about refreshing in any way.

---

@cjacky475 wrote:

... or what would be the best practice to get the new access token and store it for further calls until it expires? ...

---

As mentioned already, the simplest way is to do nothing (including once initially store your credentials don't change them). This is a good way to handle long running client object. If you construct client object for few operations in relatively short time, some optimizations may be done. To avoid refreshing the same access token meaningless, you may update stored access token (or credentials at all) at current object end of use. So on next client object' construction will not need refreshing all the time (or not mandatory, at least, but only when absolutely needed - again, handled internally). This is a good optimization step that usually don't need much more than a single line of code.

Hope this helps.

[cjacky475]

To avoid refreshing the same access token meaningless, you may update stored access token (or credentials at all) at current object end of use.

---

Hi, Здравко, thanks for the answer. That's exactly what I would need to do. Could you please elabore more on when and how exactly I would need to do that for the best practice? Let's say I perform:

client.files().download("/database.sql").download(outputStream)

Now if the access token was expired, the SDK would automatically update the access token, right? How to get it to store for further client object creations?

Thanks.

[Greg-DB]

@cjacky475 Здравко is correct; when using an official Dropbox SDK and supplying a refresh token, you do not need to catch this in your own code.

It looks like you're using the Dropbox Java SDK, so if you're interested, you can see where the Java SDK handles this error internally for you here.

[cjacky475]

Hi, Greg-DB, thanks for the answer. What if I perform a lot of operations, how is this secure to constantly use refresh token to get the access token? Is there no way to get the access token after it was refreshed internally in the SDK? This way I could store the access token and next time use it to instantiate the client object. Thanks.

[Greg-DB]

@cjacky475 The use of a refresh token works the same way whether you make a small or large number of calls. The SDK doesn't perform a refresh on every single call; it only performs the refresh when it needs to.

And as Здравко said, it is not required, but you can retrieve the current access token using DbxCredential.getAccessToken if you want.

[Здравко]

---

@Greg-DB wrote:

...

It looks like you're using the Dropbox Java SDK, so if you're interested, you can see where the Java SDK handles this error internally for you here.

---

Greg, it's almost impossible code flow to reach to there (or should be, at least). It's something like emergency way, used by exception if something in regular flow fails. Regular refresh happens here. 🙂

It's better serialization to be performed using the appropriate writer, part of the credential object, not fetching the fields one by one. 😉 Updating access token without moment of expiration is meaningless.

[cjacky475]

Remove duplicated post

[cjacky475]

Remove duplicated post

[cjacky475]

Remove duplicated post