在没有登录提示的Core Api上自动登录Dropbox帐户

本文介绍了在没有登录提示的Core Api上自动登录Dropbox帐户的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我是iOs开发的新手，我正在创建一个使用我自己的Dropbox帐户的应用。 我希望我的应用程序自动登录我的帐户，以便能够修改&在我的App的文件夹中添加文件。 文档说我应该调用： [[DBSession sharedSession] linkFromController：viewController]; 能够登录。但我不想向用户显示登录提示，因为我只想让它自动登录我的Dropbox帐户。有没有办法我可以在后台登录而不违反Dropbox api标准。我顺便使用Core API。请帮帮我。

I am new to iOs development and I'm creating an app that uses my own dropbox account. I want my app to automatically login to my account to be able to modify & add files in my App's folder. The documentation says that i should call: [[DBSession sharedSession]linkFromController:viewController]; to be able to login. But i dont want to show the login prompt to user's because i only want it to login to my Dropbox account automatically. Is there any way i could achieve login in the background without also violating the dropbox api standards. Im using the Core API by the way. Please help me.

推荐答案

Dropbox API的设计意图是每个用户都会链接自己的Dropbox帐户，以便与自己的文件进行交互。但是，技术上可以连接到一个帐户。 SDK不提供明确的支持，出于各种技术和安全原因，我们不建议这样做。

The Dropbox 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. The SDKs don't offer explicit support for it and we don't recommend doing so, for various technical and security reasons.

但是如果你确实想要走这条路线而不是启动授权流程，您将手动使用现有的访问令牌为您的应用程序。 （请注意不要撤销它，例如通过 www.dropbox/account/security 。）在iOS Core SDK中你需要使用：

However if you did want to go this route, instead of kicking off the authorization flow, you would manually use an existing access token for your app. (Just be careful not to revoke it, e.g. via www.dropbox/account/security .) In the iOS Core SDK you'd need to use:

- (void)updateAccessToken:(NSString *)token accessTokenSecret:(NSString *)secret forUserId:(NSString *)userId;

但是，这不是一个好主意。由于这将是一个客户端应用程序，您的应用程序的任何恶意用户都可以提取访问令牌并使用它来绕过您的应用程序试图强制执行的任何访问限制。例如，他们可以访问他们不应该访问的内容，或者使用其他用户可以访问的恶意负载添加或替换内容。

Again though, this isn't a good idea. Since this would be a client-side app, any malicious user of your app could extract the access token and use it to bypass any access restrictions your app attempted to enforce. For example, they could access content they shouldn't or add or replace content with a malicious payload that other users would access.