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; } } }

Production status approval for app platform

andyhasit

Hey team, I'm looking for guidance on production status approval for my Dropbox app. I'll describe what I built followed by why I need guidance.

My website has endless sub-domains which dynamically map to GitHub repos, for example:

abc.example.com/app > github.com/user1/repo1
def.example.com/app > github.com/user2/repo2

These pages all use the same barren skeleton HTML, but load their JS and CSS files from the corresponding repo (which needs to be set up a certain way) which results in a front-end app running on its own origin.

I also expose an authenticated API on my server which the apps can use to GET/LIST/PUT files (typically JSON) which the server passes on to Dropbox. The server keeps the Dropbox tokens private, so apps cannot make direct requests to the Dropbox API. It also ensures each app can only write to its designated folder, which correspond to its GitHub path. So the app loaded from github.com/user2/repo2 can only access the files in ~/Dropbox/Apps/Example/user2/repo2 - as my Dropbox app is "Folder" scoped.

The point of all this is that it lets people easily create apps that only require single-user data, like a personal habit tracker, using any frontend framework, just by pushing to GitHub. They could then share that app with other users, who can rest assured the developer does not see their data as it is stored on their Dropbox only. Users can see the source code of any app they use and contribute to it, or fork the repo, which they can then run on a new sub-domain on my site.

I've deliberately omitted a lot of detail regarding versioning, functionality and security etc, so please refrain from replying just to comment on such aspects, unless relevant to the actual questions below.

The bit on which I need guidance is this page: https://docs.dropboxapi.com/dropbox-api/docs/developer-resources/developer-guide which states that when building developer tools that wrap Dropbox each app needs its own key. I believe that may not apply to my scenario, but I would really like to know before I commit further to this idea, and I can't jump ahead and request production status as I don't have 50 users, and don't want 50 users if I have to tell them the platform won't go ahead.

The "apps" that run on this platform are essentially just user interfaces which speak to the platform's own API. They know nothing of Dropbox, which may well end up being just one of several storage options the user can choose from.

So from one viewpoint my platform does "wrap the DBX Platform for other developers" but form a different viewpoint:

The access to DBX is so restricted and controlled.
The "apps" are so limited in capacity that they can essentially be considered UIs.
The "apps" are chosen by users who are free to inspect the source code which is contentiously tantamount to them building their own UIs.

So you could argue that the Dropbox part of my platform only provides a restricted and compartmentalised file API which UIs can use to store their data, which may go to Dropbox, so its not the same thing as a developer tool wrapping Dropbox as described on the linked page.

The two reasons mentioned on that page for wanting each app to have its own key (although there clearly are others) are:

So we can let users know which apps are accessing their data.
This makes it much easier for us to debug issues when they arise.

I think I'm good on the first point given that:

My overall app is folder scoped.
Each "app" gets its own heuristic sub folder.
Each "app" has a standard menu that shows exactly which folder it uses (with a link to open it).

So it should be pretty clear to the user, in fact clearer than most Dropbox apps, what the app gets access to (in fact, why doesn't Dropbox stipulate that apps must display, somewhere in their UI, exactly which folder they access?)

As for the second point, the "apps" on my platform don't have their own behaviour as far as Dropbox is concerned, requests to Dropbox will only originate from my server.

Of course there is the issue of "what" data each app stores. I'm happy to make the server restrict it to JSON if that's the only way this gets accepted.

So the question is: is there any chance in ****** that Dropbox would approve of my platform using a single key for all the "apps" it runs, and if not, what concessions would be acceptable? I'm thinking:

Restrict file types to JSON/CSV etc.
Allow users to load apps from their own GitHub using the shared key so they can fork apps, but publicly shareable apps need their own key (which I'd still orchestrate through my server).

Thanks for reading :-)

Find more posts tagged with

API

Third Party Integrations

Comments

Здравко

Hi @andyhasit,

You're mixing different things and in such a way confuse yourself. Keep in mind that when read in Dropbox API documentation for an application, it's related to application registration in Dropbox system, which is not mandatory related exclusively to actual application developed (something you assume by mistake). The same developed application may run with different Dropbox registrations (something you mentioned about a little) and from Dropbox point of view every instantiation of such an application is… different application and this different application is described in documentation you have read.

As far as I can understand your main question, you're asking whether and how do you need to register your application instantiation that have access to your account only. Is this correct? Correct me if I'm wrong. So, in such a case you don't need to register for production and if you try, most probably your registration will get on hold (till particular users number get on - something that will never happen). Keep in mind that in your scenario, you're the only user of your application (again from Dropbox point of view) and this will stay the same as far as you keep your application key private (so nobody else could be able register as your applications user and you don't use the same application to access other accounts).

Other user of your actual application design will need to register their own application in Dropbox (with their own app key) so their instantiations won't affect your instantiation work in any way. If at some point you will let your users to access your platform with their accounts (or rather to let them use your application for processing data in their own accounts), then you will need production status. In such case Dropbox will need to inform all such users where they are going to register to (something that will appear on access granting page when they are invited to give your application access to their accounts). That's it.

Hope this clarifies matter.

andyhasit

Thank you for your comment. I'm not sure where all this confusion is coming from.

I have my Dropbox app (call it MyDropboxApp) which I can see the the developer console. It is in Development status, and has 2/500 users (just me testing with 2 different email addresses) and won't be ready for production approval until it hits 50 users, then I have 2 weeks to apply etc…

Then I have my website (call it example.com) on which visitors can run various front-end "apps" (nothing to do with Dropbox) like a todo list, habit tracker etc directly from GitHub… Let's call these "applets" to avoid confusion.

These applets can make requests to my API, say `GET example.com/api/file/todos.json` which will redirect the user to authorise MyDropboxApp to access their Dropbox files, regardless of which applet is trying to access.

The server then returns todos.json from that user's Dropbox, so they can use the todo app with their own data.

So my website uses one Dropbox app for all applets for all users. This is all working, and as far as I can see there's no confusion between apps, keys and registrations on my end.

The issue is that the documentation I linked in the first message states that using Dropox this way may not be allowed:

If you’re building a developer tool on top of Dropbox, your developers will need their own Dropbox app keys
While we encourage developers to use our official SDKs and libraries, we know there are a lot of different approaches to building frameworks and APIs. Regardless of how an app makes use of the DBX Platform, we need to know what that app is so we can let users know which apps are accessing their data. For that reason, if you provide software or services that wrap the DBX Platform for other developers to use, those developers must still sign up for their own Dropbox app key.
Use a single app key for each distinct app
If you build multiple apps, use one and exactly one key for each app you make. This makes it much easier for us to debug issues when they arise. That said, if you’re just building the same app for different platforms (for example, iOS and Android), you can use the same key.

And the question I'd like answered, preferably from someone at Dropbox who is involved in these decisions, is whether my platform counts as "software or services that wrap the DBX Platform for other developers to use".

If it doesn't, then users only need to authorise MyDropboxApp once, and can use all the applets on my site.

If it does, then each applet's developer would need to register their own Dropbox app, whose key I would upload to my server and use for requests coming from that applet, and users would need to authorise a different Dropbox app for each applet they use, which kind of kills the idea of users being able to for an app.

Hope this clarifies everything.

Здравко

Ohh.. My mistake. According Your initial post, it seemed that your service is single account service ("It also ensures each app can only write to its designated folder, which correspond to its GitHub path."), but according you last post ("…to access their Dropbox files, regardless of which applet is trying to access"). So, you would definitely need production status (or for every applet eventually).

About the rest: different app key is needed for every application that directly directs api requests to Dropbox server (something the applications/applets you're talking about don't do) and all applications that deal with end user Dropbox data directly (something no completely clear from the description of you).
You said "The server then returns todos.json from that user's Dropbox", but is this file residing in end user account or your platform dynamically generates it on user account base? Your platform/application is on the border and the last question and similar ones will provide the end result (whether it can be one application or it's a proxy for multiple applications). I believe Dropbox agent will set clarifying questions soon and will let you know the end result.

Good luck.

iNeil

Hi @andyhasit ,

Before providing definitive guidance on the app key requirements, we'd like to better understand how your platform and applets interact with Dropbox. In particular, could you confirm which of the following scenarios best describes your setup?

Only your own Dropbox account (as the main developer) would be linked to your API app.
Your website visitors who create the applets (i.e., the applet developers) would link their Dropbox accounts to your API app.
The developer applet visitors (i.e., the applet end-users) would link their Dropbox accounts to the API app.

That said, could you open a Dropbox API support ticket so our team can discuss your use case in more detail? When submitting the ticket, please confirm which scenario applies. If possible, please also provide a way for us to test the application, along with any relevant setup instructions, so we can better understand how it works in practice.

This will help us review your implementation and provide more specific guidance on the appropriate app key requirements for your use case.

andyhasit

Thanks for your reply. I think this is probably a support ticket, as you suggested, so I'll follow up that link.

But to answer your question:

The applet end-users would authorise MyDropboxApp once (so "link their Dropbox accounts") which requests access to their folder ~/Dropbox/Apps/MyExampleApp

Thereafter they can use any applet running on the site.

An todo applet developed by appdev1 would make a call to the API to fetch say example.com/api/file/data.json and the server turns that into a request to Dropbox API using my developer key to get the end-user's file at ~/Dropbox/Apps/MyExampleApp/appdev1/todo/data.json

So applet developers don't have to create a Dropbox app for their applets. They just push code to GitHub, end users visit my site and get to use the applets which reads from a predictable, isolated folder in their own Dropbox.

No app data will be stored in my Dropbox, or the applet developer's Dropboxes. It is a platform for single-user apps where the users always own their own data.