android - Cookie 或 RESTful key 的身份验证？

Question

我花了很多时间研究如何最好地实现从 Android 应用程序到 Rails 网络服务器的用户身份验证。我知道有一些引擎可以为我处理 Rails 端的身份验证，但我需要的不是很复杂，所以我认为我最好编写自己的身份验证代码。

我对 RESTful 网络服务非常感兴趣:在无状态网络服务器中，代码更具可读性、可维护性和可更改性，仅举几例优势。作为一名独立从事此实现的大学生，这些东西对我来说并不是非常重要，但我相信从编码的角度来看，REST 引导的实现仍然是理想的。

因为我的应用程序需要维护自己上下文的用户帐户，所以用户在向网络服务器发出请求时必须经过身份验证。如果我以完全 RESTful 的方式实现这个应用程序，我不会维护任何类型的 session ，而是要求 Android 应用程序(客户端)传递当前用户的凭据(可能是返回给 Android 应用程序的单个唯一 key 从第一次登录的网络服务器)在每次请求时。这将是一种有效的方法，但我担心这可能会在服务器端产生计算开销。

原因如下:

• 在每个请求中通过长字符串查找用户以便对该用户执行操作比在 CookieStore session 中为关联表行使用整数用户 ID 要慢。

• 我可能不会在数据库中以纯文本形式存储 RESTful 身份验证 key 。我可能会使用 BCrypt 并存储 key 的盐和散列。这当然会导致本项目符号解决的计算开销:使用 BCrypt 对每个请求上收到的 key 进行哈希处理，以根据存储在数据库中的哈希值进行测试。

当我最终需要对生产服务器进行托管时，我真的无法负担购买一台野兽的费用，只是为了让我可以佩戴 REST 徽章。

假设典型用户每天发出 10-30 个请求，并且用户数量取决于应用程序的受欢迎程度(我无法预测，但为了这个问题，假设是平均水平)，是不是在我的具体情况下可以 RESTfully 实现身份验证吗？换句话说，它可能产生的计算开销是否会显着增加对服务器的硬件要求？

谢谢

Answer 1

在我的项目中，我通常使用另一种方法。

一旦用户登录到系统，我会向他发送一个包含明文和加密信息的唯一生成 key 。

基本上我会做类似的事情:


key = User.id.to_s + SHA1::Digest.hexdigest("#{SECRET_KEY}#{User.id}#{User.name}#{User.created_at.to_i}")


由于 SHA1 散列的长度已知，您可以从字符串中提取 id 和 token，而无需任何特殊的分隔符。这样您可以获得两个好处:

1. 不需要将 key 存储在数据库中，因为它可以按需计算。
2. 返回给用户的 key 很短(网络优势)并且易于发送(因为在 ASCII 中，不需要 Base64 或类似的)

希望这对您有所帮助!