Child Item

AccessToken Error recovery in Auth2 (Android)

In examining the Android sample for Core API v2, I was wondering how to properly handle error recovery in the use of AccessToken. In the example, the AccessToken is returned by Auth.getOAuth2Token(), and then stored in Shared Preferences for later use, so as to avoid going through the authentication process again. I assume this AccessToken could persist this way indefinitely, as long as nothing changed. But suppose something did change. Suppose the AccessToken became incorrect, either by some action by the owner of the Dropbox account, or by some mishandling of Shared Preferences. Suppose I then tried to list the contents of a folder using the faulty AccessToken. Where would the error occur? I want to be able to detect this situation and null out my stored version of the AccessToken so that the next access attempt will result in a re-authentication with Dropbox. I don't see where in the example that possibility is provided for.

It looks like the first use of a stored AccessToken is in

sDbxClient = new DbxClientV2(requestConfig, accessToken);

in DropboxClientFactory.java in the sample. Will this fail if accessToken is bad? Or will the failure come later?

Find more posts tagged with

API

Abuse

Comments

Robert S.138

Along the same lines, can anyone tell me what the best practices are for handling sDbxClient? In the example it is a static that is set once and for all during the lifetime of the app. But in a real application, the app might have a lifespan of several days or weeks. Is there anything in the authentication process that might requiring getting a new accessToken, and therefore a new sDbxClient? Or maybe getting a new sDbxClient even if accessToken does not change?

In my application, Dropbox is accessed rarely and at user-initiated times meant to refresh a local set of files from the Dropbox copy of those files. Would it make sense if I waited until the time of the actual access to initiate the Dropbox login and creation of sDbxClient? Then after the access is over, would there be any advantage to nulling out sDbxClient so that it would be created anew the next time Dropbox access is needed? Of course I will store the accessToken in SharedPreferences and will not repeat the login process unless an error forces the issue, so that once the user logs in, the app will not require him to log in ever again (unless he changes his account). But would it make sense to make everything else (like sDbxClient) temporary?

Robert S.138

Functionally, I now have Core API v2 integrated into my app and working well. I have decided to create a dynamic DbxClientV2, rather than as a static as shown in the official sample code, and it seems to be working well. Does anyone know if this is in accord with best practices? I release the DbxClientV2 after each session of working with Dropbox, which is small part of my app. But it is possible to have several Dropbox sessions during the lifetime of my app.

So the first question remains: what will happen if my accessToken is faulty for some reason, even if it was good at one time? Here is the sequence of API calls that I do with accessToken (download from the root folder):

sDbxClient = new DbxClientV2(requestConfig, accessToken);

ListFolderResult result = sDbxClient.files().listFolder(");

List<Metadata> list = result.getEntries();

I imagine that if accessToken was bad, something would go wrong before this point. So, which call would fail, and how? (What exception, what null return, etc.?)

Karl R.2

Hi Robert,

I will try to answer all your questions. Let me know if I missed one:

Invalid Access Tokens

Whenever you issue a request using the SDK, your request may fail because your access token is no longer valid. This can happen because the token expired (very rare) or the user has revoked access to your app. The SDK will raise an InvalidAccessTokenException exception when this happens. For example:

try {
    ListFolderResult result = sDbxClient.files().listFolder(");
} catch (InvalidAccessTokenException ex) {
    // ... handle invalid token here. Probably ask user to re-authorize app
} catch (DbxException ex) {
    // ... handle all other failures
}

Note that InvalidAccessTokenException is a checked exception and is not thrown when creating a client (e.g. when calling new DbxClientV2(requestConfig, accessToken)). You will have to issue a request to determine whether the token is valid or not.

Handling DbxClientV2 Instances

The android example uses a static DbxClientV2 instances for all requests. This is safe and should not cause any problems since the client is a thin, thread-safe wrapper around your HTTP client. There are no resources that are held by the client. So you can create them as many times as you want or use a singleton pattern.

You must, however, be careful with your HTTP client. The Dropbox SDK can either use the native Java network stack or an HTTP client of your choosing. The android example uses the OkHtttp3 client for issuing requests. These clients are generally only created once for an app and shared for all network requests. A common practice is to have an HTTP client with a configured connection pool that is shared across your app. In this case, every time you create an SDK client, you would want to pass in the same instance of your HTTP client.

Below is an example of how to share an OkHttp3 client across your app and the Dropbox SDK:

OkHttpClient httpClient = OkHttpClient.newBuilder()
    .connectionPool(new ConnectionPool(8, 30, TimeUnit.SECONDS))
    .build();

DbxRequestConfig requestConfig = DbxRequestConfig.newBuilder("MyTestApp/1.0")
    .withHttpRequestor(new OkHttp3Requestor(httpClient))
    .build();
DbxClientV2 dbxClient = new DbxClient(requestConfig, accessToken);

// ... issue Dropbox requests with dbxClient
// ... issue other requests with httpClient

Let me know if you have any other concerns.