cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn more about Dropbox Replay? We’ve just launched a brand new group, find out how to join 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: 

My migration plan for Android app (short-lived access tokens)

My migration plan for Android app (short-lived access tokens)

Robert S.138
Helpful | Level 7
Go to solution

In looking at the various examples of implementing short-lived tokens in Andriod, I wanted my implementation to use more primitive methods, instead of DropboxClientFactory, PicassoClient, and DbxRequestConfigFactory. So here is what I have done, trying to pattern my code after the code in DropboxActivity, and adapting it to my existing code for the long-lived access tokens.

 

The first thing I noticed is that I cannot follow the pattern of having one block of code for USE_SLT true and another block of code for USE_SLT false, as shown in DropboxActivity. I need to be able to create a DBClientV2 from the old long-lived token, if it exists, and from a new short-lived token, if not. So the onResume method in my activity that uses Dropbox contains:

 

requestConfig = DbxRequestConfig.newBuilder("TuneLab Tuning Files 2.6").build();
DbxCredential credential = null;
if(sDbxClient == null) {
   String accessToken = prefs.getString(DBaccesstokenKEY, null);  //..old-style long-lived
   String serializedCredential = prefs.getString(DBcredentialKEY, null);  //..new-style
      //..At most one of the two Strings above will ever be non-null
   if(accessToken != null) {  //..first try the long-lived token
      sDbxClient = new DbxClientV2(requestConfig, accessToken);
   } else {  //..no long-lived token.  Try for a short-lived token.
      if(serializedCredential != null) {  //..check if short-lived already credential exists
         try {  //..expand the String to a DbxCredential object
            credential = DbxCredential.Reader.readFully(serializedCredential);
         } catch (Throwable t) {
            nullOutDBaccessToken();  //..nulls both SharedPreferences above
         }
      } else if (authWasJustAttempted) {  //..set by a button listener for "Link to Dropbox"
         authWasJustAttempted = false;  //..so we don't come here again
         credential = Auth.getDbxCredential();  //..will be null if user said NO
      }
      if(credential != null) {  //..either from serialized version, or from Auth attempt
         credential = new DbxCredential(credential.getAccessToken(), -1L, credential.getRefreshToken(), credential.getAppKey());
         if(credential != null) {
            sDbxClient = new DbxClientV2(requestConfig, credential);
            prefs.edit().putString(DBcredentialKEY, credential.toString()).apply();  //..necessary????
         }
      }
   }
}

If sDbxClient is null after onResume, the activity presents the user with only one option, which is to link to Dropbox. If sDbxClient is not null, that means either an existing long-lived or short-lived access token was in effect, or this activity has just resumed after a successful Auth flow where the user said “yes”. The reference to requestConfig is to a private member of this activity that is referenced in onResume and in a button listener when the user chooses to establish a new link to Dropbox. If the user taps that button, authWasJustAttempted is set to true upon launching the Auth attempt:

 

List<String> scope = new ArrayList<>(Arrays.asList("files.content.write", "files.content.read"));
Auth.startOAuth2PKCE(getApplicationContext(), getString(R.string.APP_KEY), requestConfig, scope);
authWasJustAttempted = true;

It seems that the call shown in onResume to

credential = new DbxCredential(credential.getAccessToken(), -1L, credential.getRefreshToken(), credential.getAppKey());

accomplises the refreshing of the short-lived access token in credential, and so credential is changed from what it was after the readFully of the serialized version. If it is changed, then shouldn't the serialized version be updated in SharedPreferences too? I didn't see that in any of the examples, so I am confused as to whether or not it is necessary. What would happen if the token got refreshed, but the next time we come to this Activity, we try to refresh it again, but starting with a very stale version of the DbxCredential? Would it work anyway?

 

Other than these changes to my old code, the rest of my app would operate as before, using sDbxClient just as it was used before in uploading and downloading files. Finally, the scope that I think I need is just "files.content.write", "files.content.read" because all my app does is upload files to the App Folder or download files from the App Folder. I also examine the metadata for files to determine their last modified date. Does that require an additional scope, or are the two listed sufficient?

 

1 Accepted Solution

Accepted Solutions

Greg-DB
Dropbox Staff
Go to solution
If it is changed, then shouldn't the serialized version be updated in SharedPreferences too? I didn't see that in any of the examples, so I am confused as to whether or not it is necessary. What would happen if the token got refreshed, but the next time we come to this Activity, we try to refresh it again, but starting with a very stale version of the DbxCredential? Would it work anyway?

The short-lived access token itself is very short-lived (just four hours) and doesn't need to be persisted to preferences each time. It's only the refresh token (and app key) that matters. The app doesn't need a short-lived access token to perform the refresh to get a new short-lived access token. Even if the previous short-lived access token is very old, the SDK can still perform the refresh successfully. The refresh token itself does not actually expire (unless the user or app revokes it).

 

Finally, the scope that I think I need is just "files.content.write", "files.content.read" because all my app does is upload files to the App Folder or download files from the App Folder. I also examine the metadata for files to determine their last modified date. Does that require an additional scope, or are the two listed sufficient?

Yes, if you just need to upload and download files, those scopes are sufficient. (Those scopes also actually depend on the "files.metadata.read" scope, so you'll automatically get that too, for reading the corresponding metadata.)

View solution in original post

2 Replies 2

Greg-DB
Dropbox Staff
Go to solution
If it is changed, then shouldn't the serialized version be updated in SharedPreferences too? I didn't see that in any of the examples, so I am confused as to whether or not it is necessary. What would happen if the token got refreshed, but the next time we come to this Activity, we try to refresh it again, but starting with a very stale version of the DbxCredential? Would it work anyway?

The short-lived access token itself is very short-lived (just four hours) and doesn't need to be persisted to preferences each time. It's only the refresh token (and app key) that matters. The app doesn't need a short-lived access token to perform the refresh to get a new short-lived access token. Even if the previous short-lived access token is very old, the SDK can still perform the refresh successfully. The refresh token itself does not actually expire (unless the user or app revokes it).

 

Finally, the scope that I think I need is just "files.content.write", "files.content.read" because all my app does is upload files to the App Folder or download files from the App Folder. I also examine the metadata for files to determine their last modified date. Does that require an additional scope, or are the two listed sufficient?

Yes, if you just need to upload and download files, those scopes are sufficient. (Those scopes also actually depend on the "files.metadata.read" scope, so you'll automatically get that too, for reading the corresponding metadata.)

Robert S.138
Helpful | Level 7
Go to solution

By the way,  I tried to run this code without making any changes in the App Console, and the

Auth.startOAuth2PKCE

produced an error 400 in the browser.  But after I went to my App Console and clicked "Migrate" (leaving all the permissions the same), then the Auth worked fine and my app works fine.  So you really do have to make that change in the app console for any of the new Auth method to work.

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Robert S.138 Helpful | Level 7
  • User avatar
    Greg-DB Dropbox Staff
What do Dropbox user levels mean?