Child Item

Minimal code needed to access a team user's space using a Generated access token on macOS

I am looking to add Dropbox access to a locally run utility in house. In other words, this project will never ship to other users and more simply it will never need to be accessed with user interaction. (It will just be selectively enumerating the storage for a known user in the team space) In the SwiftyDropbox README it says: "Once you've created an app, you can go to the App Console and manually generate an access token to authorize your app to access your own Dropbox account. Otherwise, you can obtain an OAuth token programmatically using the SDK's pre-defined auth flow. For more information, see below." So, I am assuming I could get away with just using the manually generated token. Yes? Would that persist indefinitely? Since this is not going to ship I am not worried about internal token exposure from a security standpoint. Ideally it would be running on a server without the Dropbox client installed. (At the moment the utility is written to enumerate the Dropbox space on disk)

I am also assuming I do not need to modify the .plist since I am not going to use the pre-defined auth flow. Would that be a valid assumption? Speaking of the Generated access token. After I create it on the App Console it is not there when I return to the page later. Is that normal behavior? I have attempted to click the submit button to save the state but that doesn't seem to change this observation.

In the end I would like help with the minimal path to get to something like:

client.files.listFolder(path: "")

Where client is a valid result of using the SDK and a Generated access token without going through the pre-defined auth flow.

Find more posts tagged with

API

Abuse

Comments

Scott-DB

Hi jraymonds,

Dropbox is no longer offering the option for creating new long-lived access tokens. Dropbox is switching to only issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here.

Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention. You can find more information in the OAuth Guide and authorization documentation.

For reference, while the creation of new long-lived access tokens is now deprecated, we don't currently have a plan to disable existing long-lived access tokens. (If that changes, we will of course announce that ahead of time.) That being the case, you can continue using existing long-lived access token(s) without interruption, if you have any. Also, note though that after the change you won't be able to create new long-lived access tokens.

While the change began on September 30th 2021, we released it gradually, so you may not have seen your app(s) affected until more recently. Once it applies to your app, it would apply regardless of the "Access token expiration" setting for your app, and that setting may no longer be available for your app.

Note that this is something that would need to be implemented by the programmer of the app though, so if you are not the programmer responsible for this integration, you may need to get an update from them to support this.

jraymonds

Thank you. That makes sense though the README is not 100% clear on this from a new comer's perspective even though it does mention the depreciation it doesn't specifically link it to the ability to create the Generated access token which seemed to be more of a developer shortcut rather than a production concern for the longer term.

Greg-DB

Thanks for the feedback!