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.
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
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.
Solved! Go to Solution.
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.
> 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?
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
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 126.96.36.199 and 188.8.131.52 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 don't have a better example to refer you to though. It would depend on what web framework you're using anyway.
The way we work is changing. Share and discover new ways to work smarter with Dropbox in our community.Sound good? Let's get started.
For more info on available support options, see this article.
If you found the answer to your question, please 'like' the post to say thanks to the user!