cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
We just wanted to say thank you! Check out our customer appreciation video here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Re: Questions about creating DbxClientV2 using DbxCredential

Questions about creating DbxClientV2 using DbxCredential

vewert
Explorer | Level 4
Go to solution

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/a...

 

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.

 

1 Accepted Solution

Accepted Solutions

Greg-DB
Dropbox Staff
Go to solution

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.

View solution in original post

4 Replies 4

Greg-DB
Dropbox Staff
Go to solution

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.

vewert
Explorer | Level 4
Go to solution

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
Dropbox Staff
Go to solution

No, you don't really need to do so, since the refresh token doesn't change.

vewert
Explorer | Level 4
Go to solution

Thanks again for the clarification.

Need more support?