我正在开发一个简单的 iPhone 应用程序，用户可以在其中注册并使用他们的电子邮件/密码登录。这些值存储在远程数据库中。
我正在使用 Cloudant 来存储这些信息（CouchDB 很棒），并已向新用户授予只读权限（创建的 API 密钥/通行证）。为了与 Cloudant 通信，您显然需要一个 URL 来访问它（例如 https://user:[email protected]），作为字符串存储在应用程序中。
现在，虽然我知道这非常不安全，但我想不出任何其他替代方案来保持数据库 URL 的安全（特别是它的用户名/密码）。我见过有人谈论使用另一台服务器进行代理来获取凭据，但这似乎有点尴尬。
任何帮助或想法将非常感激！
I'm developing a simple iPhone app where users register, and sign in with their email/password. These values are stored in a remote database.
I'm using Cloudant to store this information (CouchDB is great), and have granted read-only privileges to a new user (created API key/pass). In order to communicate with Cloudant, you obviously need a URL to access it (eg https://user:[email protected]), which is stored in the app as a string.
Now, while I know this is pretty unsafe, I can't think of any other alternatives in order to keep the db URL safe (specifically the username/password for it). I've seen people talk about using another server to proxy through to obtain the credentials, but it seems a little awkward.
Any help or thoughts would be really appreciated!
发布评论
评论（2）
您是否正在尝试从 iPhone 应用程序直接连接到数据库？您不应该授予您的应用程序对整个远程用户表/数据库的读取权限。迟早会有人发现并读取您的数据。无论您如何尝试混淆它，用户/密码组合都需要以某种方式存储在您的应用程序中。
您应该做的是构建一个连接到数据库并验证用户的 Web 服务。数据库密码保留在服务器上。这种代理方法并不尴尬，它是让用户远离数据库登录的唯一方法。
Are you trying to make a connection from your iPhone app directly to the database? You shouldn't give your app read access to the whole remote user table / database. Sooner or later someone would find out and would have read access to your data. No matter how you try to obfuscate it, the user/password combination would need to be stored somehow in your app.
What you should do is build a web service that connects to your DB and verifies your users. The database password stays on a server. This proxy-approach is not awkward, it is the only way to keep your database logins away from your users.
一种选择是在云中创建您自己的服务，以抽象出您的存储。这还有一个好处是允许您更改存储而无需更新所有设备。
在该模型中，服务存储访问存储的凭据，并且您在应用程序层中实现用户安全。我也不会将其视为代理层 - 这意味着它是一个薄层传递。如果您开发服务，您应该定义一个与存储无关的 Web 界面（rest、soap）。在这种情况下，它是一项服务，而不是代理。
编辑：
通常，Web 服务会对用户进行身份验证（不要编写您自己的）。使用 SSL 的基本身份验证是典型的。然后，在该服务上下文 API 中，您可以访问用户名。从那里开始，您就可以做您需要的事情。您的存储可通过对所有内容具有完全访问权限的一个存储帐户进行访问。
另一个身份验证选项是 OAuth，它允许他们向像 google 这样的人进行身份验证 - 你永远不会得到密码 - 只是来自 google 的令牌让你知道他们已经过身份验证并且他们就是他们声称的身份。例如，堆栈溢出就是这样工作的。
One option is to create your own service in the cloud that abstracts away your storage. That also has the benefit of allowing you to change your storage without updating all your devices.
In that model, the service stores the credentials to access the storage and you implement user security in your application layer. I also wouldn't think of it as a proxy layer - that implies that it's a thin pass through. If you develop a service, you should define a web interface (rest, soap) that's agnostic to the storage. In that case, it's a service, not a proxy.
EDIT:
Typically the web service authenticates the user (don't write your own). Basic Auth with SSL is typical. Then, in that services context API, you get access to the username. From there, you do you what you need. Your storage is accessed with the one storage account that has full access to all content.
Another auth option is OAuth which allows them to authenticate with someone like google - you never get the password - just a token from google letting you know they authenticated and they are who they claim to be. For example, that's how stack overflow works.