cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Share your feedback on the Document Scanning Experience in the Dropbox App right here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Implicit Grant Returns Access Denied unless localhost

Implicit Grant Returns Access Denied unless localhost

cloudlife
Helpful | Level 6
Go to solution

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, for some reason whenever I change the redirect url from: 'http://localhost:3000/loginredirect/'

to my actual cloudfront url, it stops working.

 

To be more specific this url when used with the cloudfront url: 

https://www.dropbox.com/1/oauth2/authorize?client_id=<app key>&response_type=token&redirect_uri=<redirect URI>&state=<CSRF token>

 

Does not show me the Dropbox window asking me to grant access to my app, instead it shows me:

<Code>AccessDenied</Code>

<Message>Access Denied</Message>
 
Also the loginredirect url for both localhost and cloudfront url is set on the app settings side. Not sure what's wrong, it's worked just fine before...
 
If you have any tips on what might be happening, it'd be greatly appreciated! Thank you for your time!
2 Accepted Solutions

Accepted Solutions

Greg-DB
Dropbox Staff
Go to solution
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.

View solution in original post

cloudlife
Helpful | Level 6
Go to solution

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!

View solution in original post

3 Replies 3

Greg-DB
Dropbox Staff
Go to solution
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.

cloudlife
Helpful | Level 6
Go to solution

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
Go to solution
Thanks 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
Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Greg-DB Dropbox Staff
  • User avatar
    cloudlife Helpful | Level 6
What do Dropbox user levels mean?