As a software developer company, we would like to give Dropbox feature to our native C++ MFC desktop app.
As we can't use the IE browser anymore, we have to look for another browser solution.
We tried to use CEF, and we could succesfully integrate it into our app.
Because the CEF needs so many exe instances and our desktop exe can't handle this behaviour, we use a small proxy exe to work with CEF.
We implemented the "code flow" authorization.
We use this kind of url:
https://www.dropbox.com/oauth2/authorize?client_id=<our_client_id>&force_reauthentication=false&locale=en_GB&redirect_uri=https%3A%2F%2F<our_redirect_uri>&response_type=code&state=%7B<our_state>%7D
Of course, "our_client_id", "our_redirect_uri" and "our_state" has valid values.
Unfortunatelly this authentication worklow sometimes works, but simetimes doesn't.
When not then the tipical problem is: when the small proxy exe shows the Dropbox's login screen, and we enter a valid email and password pair, and then try to sing-in, the cursor became "busy", and will never ends, so the browser won't ever redirected to the given url.
The interesting is that there are machines where this workflows works very well, but there are other machines where is doesn't.
"Doesn't work": I mean that the busy cursor remains active, and we never get redirected to the given redirect_uri (neither anywhere else).
Machines means: Win10x32, Win10x64.
Our small proxy exe is based on the CEF's cefsimple app, but we added some extra codes because we need to communicate backwards our desktop exe.
We tried the original "cefsimple" app also, and we experienced that it also can't redirect.
Then we tested with the Microsoft's Edge on the very same machine, so the Edge also suffer from this "endless process" problem.
The Edge version is: "88.0.705.50 (Official build)(64-bit)" - actually the most up-to-date version.
Is it possible that this is bug in the Dropbox?
