Need to see if your shared folder is taking up space on your dropbox 👨💻? Find out how to check here.
Forum Discussion
Solved
What way of authorization to use for a (PHP) open source module
I am the developer of the Drupal module Backup & migrate Dropbox that extends the "Backup and migrate" module to store backups on Dropbox. So this module: is open source, so I cannot put the App se...
While the PKCE flow is generally meant for client-side apps (and server-side apps would generally use the code flow) given the constraints in this case, using the PKCE flow seems reasonable and should work.
The issue you're running in to here is that you're calling /oauth2/token to perform 'grant_type=refresh_token' but are supplying the 'code_verifier' parameter. The 'code_verifier' parameter should only be provided for the initial 'grant_type=authorization_code'.
That is, the flow should look like this:
- The user is directed to /oauth2/authorize
- The user approves the app
- The user copies the authorization code from the Dropbox web site into the app
- The app calls /oauth2/token supplying 'code' set to the authorization code, 'grant_type=authorization_code', 'code_verifier' set to the code verifier, and 'client_id' set to the app key, just once per authorization flow.
- The app uses the short-lived access token to make API calls.
- The app calls /oauth2/token supplying 'refresh_token' set to the refresh token, 'grant_type=refresh_token', and 'client_id' set to the app key, but not 'code_verifier', repeatedly whenever a new short-lived access token is needed.
Also, to confirm, yes, refresh tokens are long-lived. They don't expire by themselves, but can be revoked on demand.
Hope this helps!
Remove the comma at the end, the forum software added that to my plain text link.
Thanks. I've taken a look at your code - very neat, btw.
I've extracted the code you used to build the unencoded verifier string and the encoded verifier code challenge, and inserted them both into my code. I've compared the verifier code in the authorisation url and in the token request and they are exactly the same. I'm still getting exactly the same error:
{"error_description": "invalid code verifier", "error": "invalid_grant"}Here are the headers I'm sending with the token request:
HEADERS=Array
(
[0] => Accept: application/json
[1] => Content-Type: application/x-www-form-urlencoded
)Here is the data I'm paramatising onto the endpoint (oauth2/token) for the token request:
DATA=Array
(
[grant_type] => authorization_code
[code] => <AUTHORIZATIONCODE>
[code_verifier] => <CODECHALLENGE>
[client_id] => <CLIENTID>
)(I'm not using a REDIRECT_URI in either the authorisation URL or the token request as this is for a WordPress plugin that might get used on more than one site. This is apparently perfectly okay with Dropbox, according to their docs.)
I'm at a loss. If the CODECHALLENGE is exactly the same in both the authorisation URL and the token request, why on earth is it failing?
With the token request you should pass the code verifier, not the code challenge. Dropbox will hash it itself and compare it with the code challenge that it stored when the user granted access with the authorize request. note that the code verifier should be unique for each install of your plugin and should stay on that install and only be used to obtain a (long lived) refresh token.
Hope this helps
Thanks. That seems to have done the trick. I'm sure I tried that option once before, but I must have also had something else changed that also wasn't working.
About Discuss Dropbox Developer & API
Make connections with other developers
