You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Redirect on .GetCurrentAccountAsync()
Hi, I'm using the Dropbox Api 4.9.3 for .NET, and there is some weird behavior during/after authentication. What I do is: - open a WebBrowserDialog - get authorizeUri using DropboxOAuth2Helper....
When using `OAuthResponseType.Token`, a redirect URI is required, as a security feature of OAuth 2. It's optional for `OAuthResponseType.Code` though, in which case the user can manually copy/paste the authorization code from the web site into the app. (Using a redirect URI streamlines the process by avoiding the need to have the user do that manually.)
By the way, I don't have full context on your app/platform of course, nor am I specifically familiar with the `WebBrowserDialog or `WebBrowserControl` classes you mentioned, but for reference for you if you haven't seen it, or for anyone else reading, our official documentation for processing this in the system browser via the .NET SDK can be found here.
So, I scrambled together a small test-app trying to recreate the bug, but only partially successful so far.
What I currently have is another bug, which apparently is WinForms WebBrowserControls' fault, where getting authentication and immediately closing that browser opens the redirected url in browser. (something about the redirect via script opening the actual browser instead of staying in that WinForms control)
Side-question, is that redirect-url necessary? Using Helper.GetAuthorizeUri with the Token-Flow seems to require the redirect-url, but I don't see the practical necessity for it in our case where we just get authentication and close the browser.
I'll give it another look somewhere next week when I'm back at the office, to figure out why in our actual project that redirect does not happen until the .GetCurrentAccountAsync method is called (at a point where the webBrowser should have been disposed, afaik)
Greg-DB
Dropbox Staff
Dropbox StaffWhen using `OAuthResponseType.Token`, a redirect URI is required, as a security feature of OAuth 2. It's optional for `OAuthResponseType.Code` though, in which case the user can manually copy/paste the authorization code from the web site into the app. (Using a redirect URI streamlines the process by avoiding the need to have the user do that manually.)
By the way, I don't have full context on your app/platform of course, nor am I specifically familiar with the `WebBrowserDialog or `WebBrowserControl` classes you mentioned, but for reference for you if you haven't seen it, or for anyone else reading, our official documentation for processing this in the system browser via the .NET SDK can be found here.
What I meant by the WebBrowser* was that Windows Forms control:
https://docs.microsoft.com/de-de/dotnet/api/system.windows.forms.webbrowser?view=netframework-4.8
We initially used it in combination with a text-box to do the Code Authentication-flow (where the user sees a code after log-in, and has to give it to the App somehow)Now that we moved to this Token authentication-flow, there was little reason to keep the WebBrowser control, so we moved to a solution very similar to your documentation.
Some follow-up questions:
- The first example in that documentation uses
var authorizeUri = DropboxOAuth2Helper.GetAuthorizeUri(OAuthResponseType.Code, ApiKey, new Uri(RedirectUri), state: state);
and it took me forever to find the bug in my copy-paste:
shouldn't the first parameter be OAuthResponseType.Token ? ( https://github.com/dropbox/dropbox-sdk-dotnet/blob/b8f5c751f9df6765f4e2bbb98b39bc6bde5cfadc/dropbox-sdk-dotnet/Examples/SimpleTest/Program.cs#L229 got it right)- There is no way to automatically close the redirect-url, is there? JavaScript isn't cutting it because it did not open that tab in first place, and opening url with a specific process and killing that process after that feels dirty. (that's actually what we unintentionally achieved with that WebBrowser control)
I'm fine with sprinkle-ing some HTML on that redirect-page, would just be a little cleaner if it closed itself.
Thanks for the answers so far, official documentation is a solid solution to avoid that initial bug I had.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
