I am a lecturer and I'm looking to create a coursework submission system for our students, many of whom create very large files (>5GB - they are film students). I've tried to link into Google Drive for this and have hit a roadblock in as much as their Picker (my preferred way of doing things - I want to remove the need to store uploaded files on my server when at all possible) will not allow for refreshed authorisation in the client library. So it will work for 1hour, then the auth token times out, and I am unable to get a new one without authenticating in the browser as me, which defeats the object.
So, here's what I want to do - can anyone give me some guidance on how best to implement? I've tried looking at Core API and got the basics of the theory under my belt, but the implementation is driving me crazy.
I have considered doing this through a convoluted sharing set up (e.g. manually create a folder for each student, share it with them) but a. that does not scale well past about 10 students, b. it doesn't handle case edges well and c. not every student will have or want to have a Dropbox account.
So, any ideas please? If I'm asking for the impossible, could someone let me down gently ? Also, I have researched services like DBInbox and the like and whilst they have some of my intended functionality they do not cover all areas, hence my desire to roll my own.
Forgot to mention - I usually code in PHP, if that makes any difference. I can do HTML, CSS, JS, MySQL, C#, Obj-C and a couple of other things as well if that helps...
I'll start by saying this isn't impossible, but some pieces may be a manual process right now. The API was designed with the intention that each user would link their own Dropbox account, in order to interact with their own files. However, it is technically possible to connect to just one account, as you described. It's generally not recommended, but with a server-side app like you describe, there isn't much of a security concern (like there is when doing this with a client-side app).
A few notes:
Most just a note on vocabulary, but Dropbox API apps don't "point" to any particular account. They are "owned" by the account that registers them, but that doesn't automatically enable access to that account via that app. That only happens in your item 2.
If you let your users use the Dropbox Chooser (in the case where they do have a Dropbox account) you have the choice of two different kinds of links:
"direct": This kind of link expires after four hours, and would let your app access the student's chosen file content directly (i.e., the app makes a GET request to download the content). Your app would have to download the content and re-upload it to your Dropbox though. This is of course somewhat inefficient. We're tracking some feature requests that would enable more efficient solutions here, but there's currently nothing available to help on this point.
"preview": This kind of link doesn't expire, but gives you a preview web page of the file itself. From there, you can download the file or efficiently add it to your own account. The latter is a manual process as there's currently no API endpoint for doing so. (It's just a button on the web page.)
Also, in the case where the student does have a Dropbox account, there is an alternative and much more efficient way of doing this, but it would require them to authorize your app to access their own account to, which isn't what you had in mind. For reference though, it would involve getting a "copy reference" to the file in their account once they linked the app and then copying that file into your account using that copy reference (see the
.5. Unfortunately, there currently isn't an API for managing shared folders (e.g., creating new shared folders and inviting people) so this would have to be a manual process. However, if you'd be interested in potentially participating in shared folder API beta in the future, please sign up here.
The programming language doesn't make much of a difference here in any case. The above documentation links are all for the underlying HTTP API. We do recommend using one of our official SDKs whenever possible though.
Hope this helps!
Quick follow up here on #3, we now have an endpoint for saving a file to a Dropbox account via a URL:
Hi Greg - thanks for the update. I'll have a look over the new documentation and let you know if I have any issues - but it seems to be exactly what I needed, thank you!
The way we work is changing. Share and discover new ways to work smarter with Dropbox in our community.Sound good? Let's get started.