Localhost

[angelo_costantino]

As reported by the documentation I used http: // localhost as a redirect uri. Since my system did not allow me to access this page, I installed microsoft IIS: now http: // localhost is accessible and shows a welcome page in IIS, but it does not work as redirect uri: it does not return an authentication code in the title or in the url . Can you help me? Thank you

[Greg-DB]

I'll be happy to help with any issues you're having with the Dropbox API, but I'll need some more information. Please reply with:

• the name and version number of the Dropbox SDK/library you are using, if any
• the steps to reproduce the issue, including relevant code snippet(s), but don't include any access or refresh token(s)
• the full text of any error or unexpected output

[angelo_costantino]

In the Delphi area of Embarcadero I use REST technology to take advantage of the services made available by the DropBox APIs. At the time of the authentication request (code), the system replied that the http: // localhost site was inaccessible. After trying to act on the Windows Firewall and on the router, trying to open some ports without success, I installed Microsoft IIS: from that moment my app, in the phase of returning the authentication code, simply opens the site http: // localhost , which is nothing more than a welcome page in IIS, without generating a change of the title or the URL from which to take the authentication code. The app, tested using the redirect uri provided by OneDrive  (https://login.microsoftonline.com/common/oauth2/nativeclient) , works perfectly. Thanks for the support.

[Greg-DB]

Thanks for following up. Just to clarify, do you still need help on the Dropbox API side of things? (If so, please show us what currently isn't working.)

[angelo_costantino]

As I said my app works perfectly if I use the Microsoft OneDrive uri redirect. I wonder if this is a valid solution or if instead it is better to experiment with a different redirect uri, more linked to the DropBox world. Thanks for the reply.

[Greg-DB · Accepted solution]

The redirect URI you use (if any) is up to you as the developer. It is intended to be a URI you control, but you can choose whatever is appropriate and functional for your scenario.

It's not clear how you're accessing the authorization code on the redirect URI if you don't control the redirect URI though, since that URI is on a domain/server you presumably don't have access to. Note that the OAuth app authorization flow should not be processed in an embedded browser or web view, per the documentation; it should only be processed in the user's system browser.