Child Item

How to authenticate with a Dropbox account, via oauth2, from my browser only webapp

Hi,

I want to upload a blob url from a browser only webapp (no server side) into a dropbox account using the filesUploadSession* api.
First, I need to authenticate with the Dropbox account using the oauth2 api.

I read the related oauth2 guides here
and saw the javascript sdk js examples and specifically the auth example.
The example redirects to the same example page.

In my webapp, the call to upload the file is done somewhere within one of the many js scripts, far after the creation of the main index.html page.
If I redirect to the main page, I don't know how to manage (intercept, and respond) the redirect.

The simplest and naive way for me to get the autherization token is via "implicit grant" that is explained here
But as I understand, it is not recommended to use this grant type and it is not supported by the javascript sdk js

So my questions are:
- How do I handle the "redirect" response?
- Is there a more real-life example that shows how to intercept and respond to the redirect callback?

This is probably more of a basic redirect question. The dropbox auth is just a use case that shows my problem.

Thanks,
Avner

Find more posts tagged with

API

Abuse

Accepted answers

avner1

I was able to upload using the instructions from here.
The solution was to use a popup page that polls for the URL.

All comments

Greg-DB

For client-side applications in particlar, such as in browser JavaScript, using the "token" a.k.a. "implicit" Dropbox OAuth app authorization flow is the expected and reccomended technique. That is supported by the official Dropbox JavaScript SDK. You can see it getting set in the SDK's code here if you're interested, and it's documented here. It's the default for "getAuthenticationUrl" 'authType' parameter, so the "auth" example does use it here.

Anyway, to answer your questions, the Dropbox OAuth app authorization "token" flow returns the resulting access token on directly the redirect URL's "fragment" a.k.a. "hash". So, to complete the flow, the application should check the URL for the access token and store and use it if found.

The "auth" example simplifies this a bit (and I unfortunately don't have a better example to share), by only taking the access token from the URL if found. In a real app, you'd want to store the access token once you receive it, and then check that storage first on subsequent executions to see if you have an access token saved.

Further, you may want to have your redirect URI be something different than just your typical home/main page, so you can detect if the user is coming back from the app authorization flow, instead of checking on every load, like the "auth" example does.

And finally, since you are making a browser-only web app, you may want to include some extra data in the "state" parameter that you give to getAuthenticationUrl to indicate where the user was. That way, when the user comes back on the redirect URI, you can get the data from the result, like `utils.parseQueryString(window.location.hash).state`, and use it to restore what the user was doing.

Avner11

> In a real app, you'd want to store the access token once you receive it ...
I'm ignoring the the storage of the access token problem, for now.

> Further, you may want to have your redirect URI be something different than just your typical home/main page, so you can detect if the user is coming back from the app authorization flow, instead of checking on every load, like the "auth" example does.

My problem is that I don't know how to handle the redirect.
Assuming that the redirect URI is different than the home/main page, and I can detect that user comes back from the app authorization flow, I still don't understand what the "state" should look like.

For example, prior to the authorization, a file was opened and data was read to various variables. How can all this information be encapsulated in a state?
And assuming I know how to set a state, should I redirect back to the home/main page after I parsed the access token? Wouldn't this reload the page and reset the application?

With Google Drive API, I can authorize, and continue the application flow (i.e. upload the file to Google Drive) by using a JavaScript client library.

Is there a similar library/functionality in Dropbox that will detect the redirect and let me continue the flow from where I am?

Probably my challenges are basic, due to my web programming inexperience.
I searched the Internet and couldn't find a proper tutorial, but maybe I don't know what to look for...
It would be helpful if someone could refer me to a more basic link that explains how to handle redirect, restore a state, and resume the application flow after authorization

Thanks,
Avner

Greg-DB

The "state" value for the Dropbox OAuth app authorization flow is:

Up to 500 bytes of arbitrary data that will be passed back to your redirect URI. This parameter should be used to protect against cross-site request forgery (CSRF). See Sections 4.4.1.8 and 4.4.2.5 of the OAuth 2.0 threat model spec.

Exactly what you put in it is up to you (in addition to the CSRF protection). It can be any arbitrary data/format. E.g., It could be a JSON dictionary containing information about where in your app the user was, such as what file the user was reading. (You'll probably want to URL-safe base64 encode it before you send it off though.)

The idea is that since the user will be leaving your site, you would put whatever your site would need to know when the user comes back to get them back to what they were doing. Exactly what data that would be is specific to your app.

I believe the Dropbox JavaScript SDK you're using is roughly the equivalent of the Google library you linked to. It's just a minifed JS file though, so I don't know exactly what it does. In any case though, it sounds like it serves roughly the same purpose, but the Dropbox SDK leaves the handling of your own app's state up to you.

I don't have a better example to refer you to though. It would depend on what web framework you're using anyway.

avner1

I was able to upload using the instructions from here.
The solution was to use a popup page that polls for the URL.