Take Your Search Game to the Next Level with Dropbox Dash 🚀✨ Curious how it works? Ask us here!
Forum Discussion
Solved
Questions about creating DbxClientV2 using DbxCredential
Hi,
I am looking to start using Short-Lived tokens (using PKCE and refresh tokens), and have been looking at the Android example code from: https://github.com/dropbox/dropbox-sdk-java/tree/3162efeccaca247e25553acd21f6ac0bf9018ad6/examples/android/src/main/java/com/dropbox/core/examples/android
I have a couple of questions around creating a DbxClientV2 using DbxCredential, specifically from the following code found in: DropboxClientFactory:
public static void init(DbxCredential credential) {
credential = new DbxCredential(credential.getAccessToken(), -1L, credential.getRefreshToken(), credential.getAppKey());
if (sDbxClient == null) {
sDbxClient = new DbxClientV2(DbxRequestConfigFactory.getRequestConfig(), credential);
}
}
Firstly I don't understand why a credential is passed in, and then a new credential is created. I'm guessing that has to do with refreshing the Token. I am also unclear why -1L is used as the expiresAt parameter in the constructor.
Another question I have, around this, is: Does the client object (created as above) expire when the short-lived access token expires? In my app, I have a single instance of the client (created when the app starts) that is used in several activities, to make api calls, and I'm wondering if at some point while the user is using my app, if the client will suddenly become invalid and the api call will fail?
Thank-you for your help.
By setting the expiration to -1, that sample forces the client to perform a refresh immediately (e.g., in case the actual expiration of the current short-lived access token is not known, or the stored short-lived access token is presumed to be old).
And no, when supplying a refresh token like this, the client will not automatically expire. The client will automatically use the refresh token to perform a refresh to retrieve a new short-lived access token whenever needed. The user can always revoke the app's access at any time though, at which point further calls will fail.
4 Replies
- Greg-DB
Dropbox Staff
By setting the expiration to -1, that sample forces the client to perform a refresh immediately (e.g., in case the actual expiration of the current short-lived access token is not known, or the stored short-lived access token is presumed to be old).
And no, when supplying a refresh token like this, the client will not automatically expire. The client will automatically use the refresh token to perform a refresh to retrieve a new short-lived access token whenever needed. The user can always revoke the app's access at any time though, at which point further calls will fail.
Thanks Greg, that is very helpful information. I have one follow up question:
As in the example, after the Oauth flow is completed, I store the Credential (obtained from Auth.getDbxCredential, into prefs.
Then, again like the example, I use the information from that stored Credential, to create a new Credential (using -1 as the expiry). My question is: should this newly created Credential, be stored back into prefs, replacing the old value?
- Greg-DB
No, you don't really need to do so, since the refresh token doesn't change.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
