We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
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.
Greg-DB
Dropbox Staff
Dropbox StaffThe GetCurrentAccountAsync method certainly shouldn't be opening a browser. It just makes an API call to /2/users/get_current_account. (The method definition can be found here for reference.)
Can you step through the code with a debugger when this occurs to see where/when exactly that browser is getting called up?
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
Thanks 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)
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
