MEAN Stack 中的 SPA 身份验证

在前面的部分中，我们成功地创建了用户。现在，用户登录实际上意味着什么，我们如何存储这些信息，然后又如何使用它来允许用户创建帖子或禁止它。对于单页应用程序来说，这与正常的完整堆栈应用程序的工作方式不同。在单页应用程序（如我们的 angular 应用程序）中，我们的后端有一些路由、产品，以及不是我们应用程序的产品，这是一个我们可能正在构建的应用程序。

我们通常通过 HTTP 客户端发送请求，正如我们所学到的。其中一些路由可能是受保护的。例如，我们可能可以获取产品列表，但我们无法创建新产品，至少如果我们没有经过身份验证。

在传统的完整堆栈应用程序中，我们将使用会话来完成此操作。因此，如果用户使用他的凭据登录，我们将在服务器上创建一个会话，并在 cookie 中将会话 ID 返回给该客户端，因此返回给浏览器，将其存储在那里，并且对于每个未来的请求，我们将自动发送该 cookie 并在服务器上验证它，如果 cookie ID 与我们服务器上的有效会话匹配，则授予访问权限。这就是它的核心工作原理。

这不适用于单页应用程序，因为单页应用程序后端，我们的 API 在这里是无状态的。因此，它没有连接到前端应用程序。它不关心那个应用程序。这就是为什么我们有两个单独的服务器，我们有一个节点和我们的 angular 服务器，我们在同一个项目中管理它们，但从逻辑角度来看，它们是完全分离的。我们可以将任何应用程序连接到我们的 rest API。我们可以连接一个移动应用程序。因此，当涉及到这一点时，angular 应用程序与我们的节点后端是分离的，它只是将请求发送到这些 URL，但我们的服务器不存储有关该应用程序的任何信息。因此，服务器也不存储任何会话。

因此，我们必须找到一种不同的方式来存储该身份验证信息，我们通常会使用 JSON Web 令牌来做到这一点。我们可以说，它就像一个信息包，在成功登录后被哈希成服务器上生成的一个长字符串。该令牌被发送回浏览器，我们可以在我们的 angular 应用程序中将其存储在 cookie 中，或者存储在本地存储中，这是我们可以通过浏览器访问的一个 API。

然后，此令牌作为 URL 的一部分或作为标头附加到所有未来的请求中，并且该令牌无法伪造。它以一种不可能被破解的方式进行哈希处理。我们可以取消哈希它。我们可以看看它；这没关系，但是如果我们在令牌的数据部分编辑一个字符，整个哈希值就会改变。所以我们不能伪造它，我们不能改变它，我们不能猜测它。只有服务器可以验证该令牌是否有效，因为服务器是创建该令牌的人。只有服务器知道确切的算法。

因此，我们将该令牌与任何未来的请求一起发送，然后实际上 fives 我们访问权限，因为服务器可以验证该令牌，并且只有具有有效令牌的请求才允许访问。其他请求被拒绝。

这就是我们通常在单页应用程序中处理身份验证的方式，这也是我们在此模块中处理它的方式。

我们将在下一节中实际完成所有这些事情。