nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

Best practice for using Dropbox (Java) API

Thierry W.

Hi everyone,

After tweeting a lot @dropboxapi (thanks for the support guys) it will be more convenient to post a question on here.

I am developing an open source app (https://bitbucket.org/twasyl/slideshowfx) which allows to create HTML5 slide decks. The app is a desktop app using JavaFX. I would like to allow the user of my to upload their presentations on their Dropbox account.

So I created an uploader (based on the example provided here: https://www.dropbox.com/developers/core/start/java) that works like a charm when I provide the app key & secret. Indeed I open a browser that asks the user to authenticate and I retrieve the access token.

I have also implemented a version that uses the token flow in order to not place the secret in the source code and retrieve an access token.

My point here is to know the best practice of interacting with Dropbox (and more generally with services using OAuth2 for authorization) in an open source project. In non open source projects you can easily obfuscate the code, but not really in open source ones.

So where should I put app key & secret in order to ensure security? What workflow should I follow for releasing the app without compromising the security?

Again, thank you very much.

Best.

Find more posts tagged with

API

Abuse

Comments

Steve M.

Hi, Thierry. I'm the one who was responding on Twitter. Thanks for writing in. :-)

Our general guidance is that when you’re releasing your app to be used by users, you can certainly embed your app key and secret in the app, so that the app will work and let them link it to their accounts without any additional work. You may choose to obfuscate the key/secret to at least make it difficult for someone to extract them from your app.

On the other hand, if you release the code itself, for example on GitHub, etc., you should not include your app key/secret. This way, if anyone forks the code (in essence, making their own version of the app), they will have to get their own app key. That lets the Dropbox API distinguish between the different versions of the apps, and in case one of them misbehaves, any action taken will only affect the one misbehaving version.

I hope this helps clear things up.

Thierry W.

Hi Steve,

Thanks for answering me on Twitter and on here :-)

Your explanation make sense and now I finally understand the workflow I should follow. At the beginning I thought I could have one specific workflow for the development and the release process. But a better way is to have two separate workflows: one for the development and another for the release.

Your explanation covers at least two points I've read:

- The section "Use a single app key for each distinct app" described here: https://www.dropbox.com/developers/reference/devguide

- The availability of the JsonReader#readFromFile(File) in the API which is useful for the development workflow.

Now I'll take a look how obfuscate the code using a grade plugin, but that's not relative to Dropbox

Again thanks for the support, much appreciated.