OAuth2 implicit grant (token flow) does not work in IE/.Net Winform WebBrowser

Could you share your code?

Also, have you seen https://blogs.dropbox.com/developers/2014/04/dropbox-authorization-in-a-windows-forms-app/. The code there, at least at the time I wrote it, worked. (But note that there I never tried a localhost URL.)

Hi Steve,

yes I know this Blog post and I found several such solutions. But I can't get it to work.

You can find my code here:

https://github.com/Kyrodan/KeeAnywhere/blob/develop/KeeAnywhere/OAuth2/OAuth2Form.cs 

https://github.com/Kyrodan/KeeAnywhere/blob/develop/KeeAnywhere/StorageProviders/Dropbox/DropboxStorageConfigurator.cs 

The problem is, that DocumentCompleted is not fired for the redirected URL.

Regards,

Daniel

We'll try to reproduce this. Could you tell us what version of Windows you're running on? (I assume Windows 10?)

I'm unable to reproduce this on Windows 10. I created a new Windows Forms app, added a web browser control to it, and wrote the following code. I saw a message for loading (among others), the redirect_receiver page, complete with an access token. Perhaps you can try this stripped-down version of the code and see if it works for you?

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
        this.webBrowser1.DocumentCompleted += WebBrowser1_DocumentCompleted;
        this.webBrowser1.Navigate("https://www.dropbox.com/1/oauth2/authorize?response_type=token&client_id=0pr10otpma2qtln&redirect_uri=https://www.dropbox.com/1/oauth2/redirect_receiver");
    }

    private void WebBrowser1_DocumentCompleted(object sender, WebBrowserDocumentCompletedEventArgs e) {
        MessageBox.Show("document completed: " + e.Url.AbsoluteUri);
    }
}

Hi Steve,

I tested it on 2 different Windows 7 machines and your reduced code does not work. What is different to your code: I changed app-id to my id because your app-id reached user limit.

Regards,

Daniel

Ah! I can reproduce this too, but only when the user is authorizing an app they've already authorized (so they skip the screen asking them to "allow" access). I don't understand why this makes a difference as to whether the DocumentCompleted event is fired, but it seems to. (You can try this yourself by revoking your app's access via https://www.dropbox.com/account/security and then trying again. You should see the DocumentCompleted event fire as expected.)

To fix this, I'd recommend using the Navigated event instead. This seems to reliably fire in both cases. I'm going to update the blog post to suggest that. Please let me know if it works for you.

Hi Steve,

I fixed it your way and it basically works.

But I encountered some weird behavior:

1. If authorization is done and redirected to https://www.dropbox.com/1/oauth2/redirect_receiver is performed I can grab the token from the URL. But additionally to that my standard browser (in my case Firefox) opens up with this page. That's not expected
2. If I'm not authorized in any browser the authorization flow askes to login. That's fine. But if I'm already logged in prior authorization the behavior differs whether I've already authorized the app (login page is displayed, after lgging in, not further step is required by user) or not (no login page is displayed; user has to authorize access).

Especially the first bullet point is not acceptable for me. Maybe the second could be solved by navigating first to logout page and after that to the authorization URL (that's the same behavior to other OAuth services).

Regrads,
Daniel

For #1, I have no idea what's happening, but I can't see how it would be a Dropbox issue. It certainly doesn't happen in the code I shared earlier, so it also doesn't seem to be an issue with the WebBrowser control under its default settings.

For #2, I had a little trouble following what happens under what circumstances, but it doesn't sound like the expected behavior to me. What I would expect:

1. If already logged in, no login page is displayed (i.e. no email/password fields present).
2. Otherwise, the login page is displayed.

Regardless of which of those happened:

1. If the user has an existing active access token for the app, they're not asked to authorize the app again (no screen with "allow" button). Instead, they're automatically redirected to the redirect URI.
2. Otherwise, the user is asked to authorize the app (click the "allow" button). Only after doing that are they redirected to the redirect URI.

Does that match what you're seeing or not?

Hi Steve,

I fixed my #2 by myself.

#1 is still open: On Windows 7 using your solution a web browser window is opened in the last authoriziation step (if the app was not authorized before). Your solution works on Windows 10 without glitches, can't try it on Win8/8.1.

Maybe the root cause is the different behavior of the WebBrowser control on Win7 and Win10 (seems to use different IE "compatibility"). I didn't got it fixed by myself without exchanging the WebBrowser control with another browser control (which I don't want).

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.)