![]() 3) You have a Dropbox developer account (if not, go here - they're free for Dropbox users and easy to set up). 2) You are working from Ubuntu or some other linux distro's CLI, not a GUI, and know how to do simple things like run cURL and read output from "ls". This guide makes a few assumptions: 1) You have a dropbox account (or a free trial or something - access to dropbox, basically). That being the case, I decided to channel my frustration into a more useful outlet by writing this simple guide to uploading large files from CLI via the API. It occurred to me that some of the pageviews on my rant were probably from people Googling terms in order to try to find something useful that could actually help them figure this out. Attempting to use the wrong app key/secret when using a refresh token will fail.So after writing what I hope is viewed as a SCATHINGindictment of Dropbox's awful CLI support and API functionality/documentation, I decided that, while it was a somewhat satisfying way to blow off steam, it doesn't really help anyone in the same predicament (other than letting them know they're not insane or stupid, it's just terribly implemented and poorly documented). Developers with multiple app registrations will need to keep track of which app each refresh token is for. Refresh tokens are app- and user-specific.Apps can revoke an access token (and corresponding refresh token, if any) using the /2/auth/token/revoke endpoint. For example, users can unlink apps from their account using the Connected apps page, and team admins can unlink apps from their teams using the Team apps page. Access tokens and refresh tokens can be revoked on demand though, by the app or user. Refresh tokens are long-lived and do not expire automatically. New access tokens are short-lived, meaning they expire after a short period of time. Authorization codes can only be used once each and expire after a very short period of time.The terms “app key”, “app secret”, "authorization code”, “access token”, and “refresh token” describe distinct objects which are not interchangeable.In either case, setting redirect_uri is not expected when calling /oauth2/token with grant_type=refresh_token. If the app does not set redirect_uri on the /oauth2/authorize URL, it must not set redirect_uri when calling /oauth2/token with grant_type=authorization_code to exchange the resulting authorization code. If the app sets redirect_uri when configuring the /oauth2/authorize URL, it must also set the same redirect_uri when calling /oauth2/token with grant_type=authorization_code to exchange the resulting authorization code. While the use of a redirect URI is optional, apps must be consistent in specifying or not specifying it during a given authorization flow. ![]() When using response_type=code, a redirect URI is optional, regardless of using offline access or not (or using PKCE or not).Server-side apps should use response_type=code and client-side apps should use response_type=code with PKCE.The use of response_type=code is necessary for offline access response_type=token does not support offline access. However, response_type=token is considered legacy and no longer recommended. Dropbox supports both response_type=code and response_type=token.Here’s an example of calling this endpoint using curl: Here’s an example of what the “online” flow looks like:Ĭonstruct the /oauth2/authorize URL like the following and direct the user there:Īfter the user has authorized your app, they’ll be sent to your redirect URI, with a few query parameters:Įxchange the resulting authorization code for an access token, by calling the /oauth2/token endpoint. If a user has previously authorized an app, re-authorization is typically a single click or automatically redirected. If the app needs further access after the short-lived access token expires, the app can send the user through the app authorization flow again. In that case, the app receives a short-lived access token when the user processes the authorization flow. For example, a web app that only interacts with a user’s Dropbox files when the user is actively interacting with the app would only need “online” access. If your app only needs access for a short period of time, or only needs to operate when the user is present, then you only need to use “online” access.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |