We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
Implicit Grant Returns Access Denied unless localhost
Background page: https://blogs.dropbox.com/developers/2013/07/using-oauth-2-0-with-the-core-api/
So I'm trying to use the implicit grant method of login as I have always done before. However, f...
- What's the URL of the page where you see the 'AccessDenied' output? That doesn't look like the format for an error from Dropbox. Is it your redirect URI itself? If so, I'm afraid I can't offer much help, as that would be an issue with your page, so you'd have to investigate what's happening there to cause that error.
The access denied url is on my cloudfront loginredirect url. However, there's also a difference in the way it works from Dropbox's side too.
When I'm using the implicit grant from localhost, I actually get a Dropbox page-Request for access to app folder every time I log in. However, when I use the cloudfront redirect url, it skips this page completely going straight to a access denied page.
I don't see why there was a difference in behavior from Dropbox as well.
In addition, I never defined this access denied page. It's also spitting out a RequestId and HostId.
-----------------------
SOLVED: It was an issue with the routing of the loginredirect page and the way it's managed by AWS, since it's a single page application. (To further elaborate just in case someone else runs into the same problem, essentially all urls need to point back to the index.html page. Due to limitations on the implicit grant and running a single page application)
The difference in Dropbox behavior persists even now that it's working. So apparently localhost and real redirect urls are treated differently.
Thanks for trying to help!
Greg-DB
Dropbox Staff
Dropbox StaffWhat's the URL of the page where you see the 'AccessDenied' output? That doesn't look like the format for an error from Dropbox. Is it your redirect URI itself? If so, I'm afraid I can't offer much help, as that would be an issue with your page, so you'd have to investigate what's happening there to cause that error.
The access denied url is on my cloudfront loginredirect url. However, there's also a difference in the way it works from Dropbox's side too.
When I'm using the implicit grant from localhost, I actually get a Dropbox page-Request for access to app folder every time I log in. However, when I use the cloudfront redirect url, it skips this page completely going straight to a access denied page.
I don't see why there was a difference in behavior from Dropbox as well.
In addition, I never defined this access denied page. It's also spitting out a RequestId and HostId.
-----------------------
SOLVED: It was an issue with the routing of the loginredirect page and the way it's managed by AWS, since it's a single page application. (To further elaborate just in case someone else runs into the same problem, essentially all urls need to point back to the index.html page. Due to limitations on the implicit grant and running a single page application)
The difference in Dropbox behavior persists even now that it's working. So apparently localhost and real redirect urls are treated differently.
Thanks for trying to help!
- Greg-DBThanks for following up. I'm glad you got this sorted out already.
And for reference, yes, in certain cases Dropbox will automatically redirect you through the OAuth flow if you've already authorized the app. It won't do so if you're using a localhost redirect URI. The information sent to the redirect URI don't change based on that though. If you want, you can disable that automatic redirect behavior using force_reapprove=true:
https://www.dropbox.com/developers/documentation/http/documentation#oauth2-authorize
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
