Child Item

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.GetAuthorizeUri(OAuthResponseType.Token, m_ClientId, m_RedirectUrl, m_Oauth2State, forceReauthentication: true);
- navigate to that Uri
- get the OAuth2Response using DropboxOAuth2Helper.ParseTokenFragment(redirectUrl);
- save that OAuth2Response and close the WebBrowserDialog

so far so good, the OAuth2Response is usable and I can create a working DropboxClient whenever I need

When I first access the dropboxClient.Users.GetCurrentAccountAsync-Method, it opens my browser with the empty redirect-url (title something with authentication successful)

I don't get where that's coming from and why.

The workaround I found was to keep the WebBrowserDialog open and do the first call to client.Users.GetCurrentAccountAsync() there, so it opens the empty redirect-url, but within that browserDialog, which I immediately close afterwards.

Find more posts tagged with

API

Abuse

Accepted answers

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.

All comments

Greg-DB

The 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?

Viggaaa

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?

Viggaaa

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

Viggaaa

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.

Greg-DB

I'm glad to hear you got this sorted out. Yes, that appears to be a mistake in the first code block there. Apologies for the confusion. I'll ask the team to fix that up.

And that's correct, unfortunately we don't have a way to close the browser tab itself.