I notice that the Dropbox API has now officially dropped support for Internet Explorer, which means that any Windows desktop application that integrates with Dropbox is now faced with an uphill battle:
Previously, we could just use the Internet Explorer-based WebBrowser ActiveX control, which allowed us to hook into navigation events and parse the access token after the user completed the authentication/authorization process.
It looks like the only option available to us now is for our desktop applications to host an entire HTTP server and listen for requests to the redirect URI. The Dropbox API includes a C# example that does this using the HttpListener class. This uses http.sys, which (since Windows Vista) requires either an elevated process, or for a URL reservation to be made by an elevated user. Does the Dropbox team seriously expect desktop apps to require admin privileges in order to handle the OAuth flow?
Realistically, what are the options for handling OAuth in Windows desktop apps now? Hosting an HTTP server locally is hugely inefficient and resource-intensive, particularly if additional third-party dependencies are needed in order to avoid using http.sys. Is there perhaps a way to use a custom URI scheme to handle the redirect URI from the user's web browser? Or any other lightweight alternative?
