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.
I am fairly certain it is that method, unless I made a mistake during authentication somewhere (even though it apparently succeeded and I can use the api, download/upload files and so on)
That method was used in several different contexts during my code. Sometimes to get account for the email, sometimes to simply check the connection, ... and I made a break-point on all those calls. The first call on that method most times (not always) opens that redirect url in my browser, calls after that do not.
Tested it on two other computers in the office, same problem.
I'll take another look at the webBrowserDialog, maybe it's doing some behind the curtain magic and throws that redirect to my browser. Just not sure why it would be that much later where the dialog is closed and alraedy should be disposed.
Greg-DB
Dropbox Staff
Dropbox StaffThanks for following up. I can't find any reason that GetCurrentAccountAsync would somehow open a browser itself. The code for it doesn't have anything to that effect, and it's not doing it in my testing.
Can you perhaps make and share a small sample project that reproduces this issue so we can investigate it 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
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.
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.
