authorization_code grant running right thru and not asking for App permission.

[mjoyner1]

@Greg or moderator - can I post my client ID?

https://www.dropbox.com/1/oauth2/authorize?response_type=code&client_id=XXXXXXXXX&redirect_uri=https...

The above with the correct Client ID runs right to the redirect_uri without asking for permission. On my local development environment, it works fine with the localhost redirect. This is our staging server.

If I take out the redirect URI, it will ask for App Approval, if I put it in, it runs right thru.

[Greg-DB · Accepted solution]

Yes, it's safe to post your client ID as long as you don't mind exposing your app name. Client IDs aren't considered secret values.

Anyway, this behavior is expected in some cases. That is, if the user has already authorized the app to access their account, Dropbox may automatically redirect the user to the redirect URI without having them explicitly authorize it again.

If you'd like, you can disable this behavior using force_reapprove=true on /authorize:

https://www.dropbox.com/developers/documentation/http/documentation#authorization

[mjoyner1]

Greg, 

Thank you for shedding some light on this. For some reason, my localhost always forces the reapprove. Thru a strange course of events, we have discovered that we actually have a hostname issue in building the /token redirect and thus........ it doesn't match and no token.

Your answer is awesome and thank you for your exemplary work in this forum.

[Greg-DB]

For reference, it is expected that the automatic redirect won't happen in all cases. For example, it will only occur if the redirect URI starts with https://.