在非 100% AJAX 的 Ajax 应用程序中使用 HTTP 身份验证的最佳方法是什么

Question

我有一个标准的 HTML 登录页面，我更愿意使用它，而不是浏览器提供的标准 HTTP 身份验证弹出窗口。今天，我使用会话cookie来跟踪登录后的会话，但我希望是无状态的并每次都通过HTTP身份验证。我正在访问的网络服务已经支持这一点，所以这只是浏览器的问题。

在 jQuery 中添加身份验证凭据很简单，但我不知道如何保留它们。如果您从登录页面（一个 jsp）转到主页（另一个 jsp），您显然不会保留登录页面中的用户名和密码字段。我知道如果您从弹出窗口输入 HTTP 身份验证凭据，某些浏览器会存储它们，但我不知道使用 XHRRequest 时是否会存储它们。如果是的话，浏览器之间是否有很大的一致性？

此外，用户还需要能够“注销”应用程序。如果浏览器存储了身份验证凭据，是否可以使用 JavaScript 清除它们。

我觉得我不能成为第一个尝试解决这个问题的人。是否有一些 jQuery 插件或者已经可以处理这个问题的东西？或者根本不可能做我想做的事？

Answer 1

您有 2 个选择：

1) 客户端存储凭据——这不是一个好主意。出于明显的原因，您不想在客户端上存储用户名/密码。如果您有密码的哈希版本，它可能不会那么糟糕，但仍然不推荐。无论如何，如果您要在客户端存储，则必须使用 cookie，或者 HTML5 本地存储（尚未得到广泛支持）

2) 服务器端凭证存储——通常通过会话完成。 将生成的会话 ID 传回客户端，并保存在 cookie 中或保存在每个后续 AJAX 调用的 URL 中（例如 ?SESSID=xyz）。

然后，可以 最安全、最可靠、最容易实施

Answer 2

好的，我会尽力帮助...

首先，了解 HTTP 身份验证的工作原理。有两个版本 - 基本版和摘要版。基本以明文形式传输，摘要以加密方式传输。通过这些类型的身份验证，用户名/密码将在每个请求的 HTTP 标头中传递。浏览器在登录时捕获这些信息，并将它们存储在无法访问的浏览器会话 cookie 中，该 cookie 在浏览器会话关闭时会被删除。因此，在回答您的问题之一时，您无法从 javascript 访问这些内容。

您可以为用户名和密码创建自己的会话 cookie 变量。用于此目的的 jQuery 函数非常简单。请参阅 jquery-cookie 模块作为如何设置会话 cookie 的示例。这些可以从会话 cookie 中检索并与每个 ajax 请求一起发送并在服务器中进行验证。然而，这并不是一种特别好的身份验证方法，因为嗅探网络将允许任何人轻松获取您的身份验证详细信息。但是，它会起作用。

使用基于会话 cookie 的身份验证（其中会话 ID 随每个请求一起发送）是实现此目的的最佳方法。在服务器端，您需要为每个 HTTP 请求调用一个函数。该函数应执行以下操作：

   check to see if the session has been authenticated
   if no:
       redirect to login screen
   if yes:
       do authorization and allow the user access to the page

大多数 Web 框架支持会话 cookie 身份验证和服务器上会话 ID 的管理。这绝对是要走的路。

Answer 3

这很有趣。

使用 cookie 管理服务器上的用户会话。当用户第一次访问登录页面时创建一个会话，并通过响应将会话 ID/密钥作为值传递给其中一个 cookie。当用户通过身份验证时，将用户“密钥”信息放入 cookie 中，将“值”放入服务器的应用程序上下文中。用户登录后，任何后续请求都将根据服务器上的会话 cookie 值进行身份验证。授权将根据作为 cookie 值传递的用户“密钥”来完成。

注销时，从服务器清除基于会话的 cookie，并将站点刷新到默认页面。

Cookie 对于不同的浏览器来说很奇怪 - 只是一个注释；）

希望这会有所帮助。

Answer 4

更新

下面的答案是在 2012 年发布的，链接大多已失效。然而，从那时起，使用 JSON Web 令牌< /a>.这是一篇好博客文章，解释了如何使用它们。

---

大多数答案都没有抓住重点，即避免进行任何服务器端会话。我不希望服务器中有任何应用程序状态。我将奖励最接近的答案，但真正的功劳归于 rest -讨论组和乔恩Moore 提供正确答案，并感谢 Mike Amundsen 帮助我真正理解它。

我得到的最佳答案是使用 cookie，但不是大多数应用程序服务器提供给您的典型自动会话 id cookie。 cookie（将自动随每个后续请求发送）是由服务器签名的用户标识符和时间。您可以在 cookie 中包含过期时间，以便它模拟服务器上典型的 30 分钟会话（这意味着您必须通过后续请求将其向前推进），并防止相同的 cookie 永远有效。

XHR/AJAX 部分是转移注意力的部分。无论您是执行 XHR 请求还是老式的逐页 Web 应用程序，这都适用。要点是：

• cookie 在后续请求中自动发送，因此没有
  需要特殊的脚本 - 这就是浏览器已经工作的方式。
• 服务器不需要为用户存储任何session，因此用户
  可以访问集群中的任何服务器，而无需重新进行身份验证。

Answer 5

有点有趣的是，您考虑将一些真实信息推送给客户端。如果您想要一个传统的解决方案，KOGI 的服务器端建议是您的最佳选择。

但您似乎也在询问有关涉及用户提供的秘密的内存泄漏的问题。好问题。但要总体回答这个问题，我想说它必须是特定于浏览器的。它是浏览器内部结构、javascript 引擎内部结构相关的，客户端应用程序（即浏览器或浏览器中的 js）存储用户输入的值。

这些值很可能不会在整个内存中不必要地复制，但无法保证这一点。除了负责任的 JavaScript 编码实践之外，您无法采取任何措施来保证用户输入位置的限制。

稍微离题

基本点是，如果您将其存储在客户端上，那么它并不是真正安全的 - 除非服务器使用只有服务器（或用户通过他们的密钥）才能在客户端上存储加密信息。正确的凭据），有。因此，您可以想象编写一个 JS 应用程序来在客户端上进行一些身份验证 - 与银行卡（过去？）通过检查卡上的 PIN 码而不是返回数据库来进行 POS 身份验证的方式非常相似。它基于（有点脆弱）假设，即用户无法直接读取/写入客户端上的“暗区”cookie/本地存储/银行卡上的磁条。因此，我仅建议将此作为虚假身份验证者的取消资格，而不是作为凭证的唯一限定符。

要点

如果您确实想要无状态，只需将用户凭据存储在本地存储中，或者作为 cookie 但使用服务器密钥对其进行加密。当您需要它们时，通过 HTTPS 将带有加密/使用存储凭据的 XHR 发送到服务器，让您的服务器解密它们并将它们发送到回调。然后传递这些 HTTPS 的明文来进行您的身份验证。