Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
Currently I'm developing a .Net WinForms desktop app.
I initiate a token-based OAuth2 flow with this URL in IE11 (or to be more precise: the WebBrowser control of .Net WinForms):
I can login to an account and apply accept the app request. After that I should be redirected to <myRedirectUrl>
I get two different results:
1. If <myRedirectUrl> is "http://localhost" then I get "dnserror.html" in browser. Thsi should not happen.
2. If <myRedirectUrl> is a real URL I get redirected to the page. But: since it seems to be some JavaScript.Magic to redirect, the page is "redirected/reloaded": neither DocumentCompleted event nor Navigating event is fired. Therefore I never can determine, when the redirected page is displayed in browser. For me the best woult be, if Navigating event would be fired.
What can I do to get the result by code like for other OAuth2 providers?
Regards,
Daniel
Please let us know what you learn about the Windows 7 issue. Again, it can't really be the fault of Dropbox itself, but maybe there's a bug in the WebBrowser control? (Or maybe there's some *expected* reason why the WebBrowser control is supposed to launch an external browser, but that would be surprising.)
Hi Steve,
I want to report I'm seeing similar issue when running the WebBrowser control under Windows Vista. It is most probably a bug/incompatibility in the WebBrowser. My current suspicion is that the WebBrowser control have an issue handling a redirect url which includes fragment (#) in certain situations. My question to you is why Dropbox does the redirect with fragment and not the regular query (?) tag when doing the token flow?
Here are the steps to reproduce the issue in my environment.
1. Using token flow authorization.
2. The application has already been authorized.
3. The WebBrowser control opens a page asking to enter credentials. Enter credentials and press 'Sign in'.
4. The WebBrowser Navigated event is called. However everything after the fragment (#) is removed.
Handling the DocumentCompleted or Navigating events is not working either.
-------------------------
One more interesting observation. If I don't close the Desktop application and re-open the dialog containing the WebBrowser control, the Dropbox doesn't ask me for credentials and the token flow is called properly with the access_token fragment included.
"why Dropbox does the redirect with fragment and not the regular query (?) tag when doing the token flow?"
That's how OAuth 2 works. As to why OAuth 2 works that way, it's to prevent the token from being sent to the server. The query string is part of the URL that's sent to the server, while the fragment is not. The token flow is for client-side apps, so the fragment is a way to communicate the token to the app without having it leak elsewhere.
Nekobul, the behavior you describe sounds different from either of the issues already raised in this thread. It sounds like the Navigated event is called but the URL you see is lacking the URL fragment. Is that right?
One guess: if you're using https://www.dropbox.com/1/oauth2/redirect_receiver as your redirect URI, that page removes the fragment of the URL after a short period (e.g. to keep someone from copy/pasting the URL and leaking their token somewhere). Is it possible that Navigated is firing multiple times: once for the initial load of /redirect_receiver (with the URL fragment) and then once after the fragment is removed? Try logging/alerting in Navigated to see if it's being called more than once. The first call is the only one that will have the fragment.
Steve,
Thank you for the quick reply! When tracing using the Fiddler app, I see the following:
1. GET https://www.dropbox.com/oauth2/authorize request and Dropbox responds with 302 redirect with https://www.dropbox.com/1/oauth2/redirect_receiver#access_token ...
2. GET https://www.dropbox.com/1/oauth2/redirect_receiver request and then response from dropbox.
I get only one call in the Navigated event handler and it contains only : https://www.dropbox.com/1/oauth2/redirect_receiver#
Nekobul, can you share your code for how you're getting the URI in your Navigated event handler?
The issue I'm seeing is very similar to the issue described here. However I'm not using WPF. The WebBrowser is the standard Windows Forms.
Steve,
The code works fine if I reload an other already authorized page. When running under the debugger, the supplied Url from WebBrowserNavigatedEventArgs is clearly maimed when authorizing initially.
Have you tried DocumentCompleted or maybe Navigating?
Also, have you tried using a different redirect URI, like https://www.example.org? I'm just curious if this relates to the JS on the page removing the fragment or if it's somehow an inherent issue with the event you're listening for.
Steve,
Yes, I have tried DocumentCompleted and Navigating. The fragment is not removed by Dropbox. As I've said I can see in Fiddler the correct redirect url with the fragment is provided. My suspicion is that the WebBrowser control has an issue handling the fragment element in certain situations. So the sequence which fails is:
1. The Dropbox page for authorization is opened.
2. The page expects entry of credentials and then pressing Sign-in.
If there is no user interaction involved, the fragment is properly provided in the Navigated event. If there is a WebBrowser user interaction involved, the fragment is maimed in the Navigated event handler.
"The fragment is not removed by Dropbox."
/redirect_receiver has JavaScript on it that removes the fragment after the page is loaded. The reason I'm asking about other redirect URIs is because they won't have that behavior.
Hi there!
If you need more help you can view your support options (expected response time for a ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!