Authenticating with Dropbox

 In CloudRail

Authenticating with Dropbox

In this post we will guide you through the process of setting up your application for the use of Dropbox. There was a policy change in the way developers are supposed to handle authentication with Google services. Because Dropbox allows login with Google accounts, this change also affects the way you have to authenticate with Dropbox. Therefore, the setup is slightly different than the one you know from other services. The following paragraphs will illustrate the changes required to successfully configure a Dropbox application as well as the correct use of the advanced authentication.

What is CloudRail Advanced Authentication?

By default, CloudRail uses in-app-WebViews to perform user logins. When using Dropbox, it is however necessary to login users using an on-device browser because Drobox does not allow user logins from in-app-WebViews (except if your app’s status is “Development”). This is what CloudRail’s Advanced Authentication feature is for: it redirects the user to the service’s website in a browser on their device. After logging in, the website will redirect the user back to the app, passing along an authorization code. The CloudRail SDK takes care of all steps it possibly can, yet there are some minor steps that need to be handled within your application.

Using CloudRail Advanced Authentication with Dropbox

There are three possible ways how you can make Advanced Authentication work that are described in the following. For all of them, set up the CloudRail SDK as usual, create the service and activate the service’s Advanced Authentication feature. The other steps depend on the method you choose.

Redirecting your Users to a CloudRail website

The first possibility is to set your Redirect URI to https://auth.cloudrail.com/YourPackageName or https://auth.cloudrail.com/YourBundleID. Our website will then call your app using the package name or the bundle ID respectively. This is the easiest way of implementing Advanced Authentication, but it implies that your users’ authentication codes will be passed along via the CloudRail servers.

Java / Android

iOS (Objective C)

iOS (Swift)

Redirecting your Users to your own website

The second possibility is that you set up your own website that will redirect the user to your app, using its package name or bundle ID. You then have to set this website as the Redirect URI. For this solution, you don’t have to trust our servers’ integrity, but you will have to set up the website yourself. On the client side, you have to take the same steps as mentioned above except from changing the redirect URI.

Letting your app listen to URL calls

This solution is not possible on iOS, but only on Android. Instead of using a website that redirects to your app, you let your app listen to the Redirect URI. Therefore, you should set the Redirect URI to a website that wouldn’t be called by the users themselves, for example https://www.cloudrailauth.com/auth. The advantage of this solution is that you don’t have to implement the server-side redirect to your app. However, since you’re listening to a regular URL, the Android OS will not directly switch to your application. Instead, it will present the user a list of applications that can open URLs (including installed browsers) so that the user can choose from them. For this approach to work, the user has to recognize and choose your app from the selection.
The steps for this are the same as setting up a listener for your package name described below, but instead of your package name, you have to indicate your website’s URL.

Common final steps for all solutions

When not using Advanced Authentication, the SDK will just grab the authentication response from the webview that opened the login page. But because we open that page in an external browser, we have to tell the OS that our app should handle URLs that correspond to the redirect URI. This is done by adding the following pieces of code to the AndroidManifest.xml file if you’re using Android, or to the info.plist file if you’re using iOS:

Android

Add the intent filter to the Activity that triggered the authentication. Notice that we add <em>android:launchMode=”singleTask”</em> to the activity which will prevent Android from restarting your Activity when performing the redirect.

iOS

Add the following right underneath the top level.

What we have achieved so far is that we open the external browser for the authentication. And we listen for the redirect that is performed when the user grants access. Now we have to handle the information coming back. For both, Android and iOS this means, implementing a certain method. This method needs to pass the information to our SDK. Here is the code for the different platforms:

Android

iOS (Objective C)

iOS (Swift)

Examples

You can look at the UnifiedCloudStorage examples on our GitHub page to see Advanced Authentication with Dropbox in a working example. You can find them here:
Android: https://github.com/CloudRail/cloudrail-si-android-sdk/tree/master/ExampleProjects/UnifiedCloudStorage
iOS (Objective C): https://github.com/CloudRail/cloudrail-si-objc-sdk/tree/master/Examples/UnifiedCloudStorage
iOS (Swift): https://github.com/CloudRail/cloudrail-si-ios-sdk/tree/master/Examples/Cloudstorage

Recent Posts