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

API v2 for iOS, Mac OS X, Windows, Linux, Android - need strategic advice

Robert J.35

Hi,

I need advice on implementation of Dropbox API v2 for all platforms mentioned in the subject. I have an app that currently uses iCloud to sync data between iPhone, iPad and Mac and would like to use Dropbox to do the same on all platforms. Currently I use Dropbox Core API v1. I managed to take my iCloud implementation and in a few days I replaced iCloud API calls by Dropbox API calls. It works great, but Dropbox API v1 is deprecated. This was my first implementation of Dropbox and I just wanted to see how difficult it would be to implement Dropbox. Now I need the final version, unfortunately API v2 for Objective-C is not released yet. The question is if there is a solution, which would work on all platforms. I could use Python on desktop computers, Objective-C (or perhaps Swift) on iOS and Java on Android, but it is just too much code to maintain.

I use the same C++ code for business logic on all platforms, C++ for UI on Windows, Linux and Mac OS X and Objective-C for UI on iOS. The best solution would be API v2 for C++.

Is there a C++ implementation, which would simply use API v2 directly through HTTP calls?

If not, I could implement it myself, but there are other potential issues. For example OAuth2 response type "token" requires custom URI", which has some issues on iOS 9.2 and 9.3. It is also possible that Apple discontinues custom URIs, which means OAuth2 used this way might not work on future versions of iOS. I could use response type "code", but that requires browser-like capability (or webview if I use iOS term), so that user could enter username and password. This isn't a very good user experience, because my app is rich client. Perhaps I could parse html and submit username and password and then parse resulting html to read authentication token. But any of these solutions aren't ideal.

Is there a better solution?

Would it be possible to send simple HTTP request with app id, username, password (ideally this would automatically approve the app in user's dropbox account) and get HTTP response with token???

Does anybody have a good solution for API v2 involving just one code for all platforms?

Thanks.

Find more posts tagged with

API

Abuse

Comments

Robert J.35

Note: I don't want to use a solution, which would require installing third party components, like Java. It should be native to the platform. C++ works on all mentioned operating systems, but there doesn't seem to be Dropbox API v2 for C++.

I'm also willing to switch to another cloud service, if I can get multi-platform API.

Or should I stay on API v1 (until it expires) with Objective-C on iOS and implement for example Python on desktop computers? I'm using open source library, which has Python integrated, but not on iOS.

I would really appreciate some strategic advice, how to solve this. The ideal is final solution I don't have to change in the future, once it is implemented.

Greg-DB

Hi Robert, our normal recommendation is to use the platform specific SDK for each platform, as available. So, that would be SwiftyDropbox for Swift (and the forthcoming Objective-C library for Objective-C. ETA August), the .NET SDK for Windows, the Java SDK for Android, etc.

If you need to support all of these though, that indeed could be more overhead than you'd want, as you mentioned. It sounds like an official C++ SDK would be a good solution for you, but unfortunately Dropbox doesn't offer one. I'll send this along as a feature request though.

That being the case, you can implement the HTTPS endpoints directly in your own C++ code:

https://www.dropbox.com/developers/documentation/http/documentation

That sounds like it may be a good solution for your scenario.

Using the upcoming Objective-C library for iOS and Python on desktop like you mentioned also seems like a good compromise though. Of course, that's really up to you.

Regarding the authorization flow, I'm not sure what issues you're referring to on iOS 9.2 and 9.3, but I don't expect OAuth to be a problem on iOS going forward. (We've been using it on iOS for a long time without any major issues.) Further, you don't necessarily need a "custom" URI. There are various ways to handle it, but for example if you process the app authorization in an in-app browser, you can use a more standard redirect URI, e.g., https://www.dropbox.com/1/oauth2/redirect_receiver , which Dropbox offers for this purpose.

In any case, the app authorization flow does need to go through a browser. Your app shouldn't handle the user's credentials directly.

Also, your app should never scrape/parse the HTML of the Dropbox web site itself. In addition to being a brittle implementation, since the site changes without notice, that's against the Dropbox terms ( https://www.dropbox.com/terms#acceptable_use ). All of the platforms you listed have browsers anyway though, so that shouldn't be an issue.

Hope this helps!

Robert J.35

Hi Gregory,

thanks for response. I'm already looking at the docs and it looks like I will be going the c++ way with http post + json.

I understand that authorization flow should be handled by Dropbox web site. I'm just thinking that when it comes to security there isn't much difference between that approach and for example sending http post request with user name and password as parameters in json, and then getting response with access token. It would provide seamless integration, more like iCloud. It is true, that user would have to trust the app to let it handle username and password, user would have to trust that the app doesn't store this username and password, because this provides access to entire Dropbox account, not just app folder. The app would have to save only access token. But handling this with in-app browser isn't a better approach. Malicious app could provide in-app browser and show exact same interface as Dropbox web site, so user wouldn't notice any difference.

When it comes to security I would actually prefer a different solution:

1. MyApp would send http request with app id, app secret string, user id and a random token generated by the app (and perhaps name of the device, so the user could better identify that it is his/her request).

2. User would receive notification on the device (if enabled) - like iOS or Mac OS X notifications.

3. User would start Dropbox client (on iOS, Android or desktop client) and approve the app through Dropbox client, because only this app can be trusted when entering Dropbox password.

4. User would switch back to MyApp and it would simply send another http request with app id, app secret string and random token generated before. The response would contain access token. The random token would assure that only the client, who sent the request, would receive access token.

Advantages:

1. User doesn't have to trust the app with Dropbox password

2. Every user would more likely install Dropbox client (good for Dropbox). Today you don't really need to install Dropbox client, which means user is less involved with the Dropbox ecosystem.

3. No custom URLs need to be defined - it may be tricky on some platforms, also launching app through URL scheme may be a security weakness, if the input is not handled properly.

4. Potentially it could serve to detect denial of service attacks - someone generating too many requests for app authorization.

it's just a thought. I can implement whatever interface is currently available. The only problem is that doc says API v2 interfaces are "BETA - Not ready for production". I was hoping to have something I could release in 2 weeks or so.

Greg-DB

Thanks for the feedback and recommendation! This looks very interesting. I'll send it along to the team.

As it stands though, API apps do need to process the app authorization using the OAuth flow, either via the user's own default system browser (preferably) or via an in-app browser.

Also, API v2 is production ready. I believe the "BETA - Not ready for production" label you're referring to is just on some of the newer endpoints in the documentation (e.g., for the new "file properties" feature). The rest are not beta though, and are ready to use. Let me know if you're looking somewhere else though, as that might just be an old label we didn't clean up yet.

Robert J.35

Gregory, you seem to have team's ear, so I have another idea for Dropbox. It would be nice if Dropbox could regularly send a message with list of new apps (with links to app store), which support Dropbox, to users who signed up for receiving newsletter. It could be sent for example once a month (or even less frequently to avoid spamming users). Something like this:

Checkout new Apps designed for Dropbox:

BlahBlah123 - photo editing app

BlahBlah456 - password manger

BlahBlah789 - office app

That would help developers (like me ;-) and users might be curious and perhaps look at some of those apps. Developers would be very happy to have millions of users checkout their apps. This way Dropbox ecosystem would grow even faster, users would become more dependent on the service and perhaps sign up from premium service with more storage. But it's not anything of high priority.

In any case, thanks for info on API v2.

Greg-DB

Thanks for the idea Robert! I'm sending it along to the team now.

pjoseph

Any luck on getting a c++ restful api for dropbox approved.

@Greg-DB wrote:
Thanks for the idea Robert! I'm sending it along to the team now.

Greg-DB

No, unfortunately I'm not aware of any plans for a C++ SDK for API v2 at this time. I'll add your request though.