BoilerplateJS：处理授权和身份验证的推荐方法 [英] BoilerplateJS: recommended way to handle authorization and authentication

问题描述

使用 BoilerplateJS 设置，处理授权和身份验证的推荐方法是什么？

With BoilerplateJS setup, what is the recommended way to handle authorization and authentication?

显然，在服务器端，您需要检查cookie等以了解谁已登录。但是，在客户端，您如何知道用户是否已登录以及他们的用户名等是什么？

Obviously on the server-side you'd check cookies etc to know who's logged in. But, on the client, how would you know if a user is logged in and what their username etc are?

推荐答案

我将在其中一个使用BoilerplateJS的项目中分享这是如何完成的。在这个项目中，我们使用OAuth 2.0进行身份验证。

I will share how this was done in one of the projects that used BoilerplateJS. On this project we used OAuth 2.0 for authentication.

• 我们有一个单独的登录页面，它不使用BoilerplateJS或复杂的JS。保持分离的原因是身份验证可能依赖于URL重定向，而JS不能很好地处理。

• We had a separate login page which was NOT using BoilerplateJS OR complex JS. The reason to keep it separate is that authentication may depend on URL redirection, which is not handled best with JS.

一旦用户被正确认证，我们就会收到服务器会话的auth_token并将其存储为JS变量。我们使用全局Boiler.Context的设置来存储此令牌。由于设置被继承到子上下文，我们可以从任何地方访问它。

Once user is correctly authenticated, we receive the auth_token of the server session and store it as a JS variable. We used 'settings' of global Boiler.Context to store this token. Since settings are inherited to child contexts, we were able to access it from any where.

出于授权目的，我们然后下载了一个简单的ACL用于记录包含授权访问密钥的用户。这些键仅用于显示/隐藏控件的客户端验证。实际授权是在后端服务上执行的。

For authorization purposes, then we then downloaded a simple ACL for the logged user that contains the authorized access keys. These keys were just for client validations to show/hide controls. Real authorization was performed on backend services.

我们希望BoilerplateJS组件完全自包含，包括对其进行身份验证。因此，如果某个特定组件的viewmodel从服务器接收到未经授权的401 HTTP响应（未登录OR或会话到期），我们会以不同方式呈现组件，而不会将用户重定向到登录页面。

We wanted the BoilerplateJS components to be fully self contained including authentication of it. Therefore if a particular component's viewmodel receive an unauthorized 401 HTTP response from server (either not logged-in OR or session expiry) we rendered component differently there, without redirecting user to the login page.

由于我们没有重定向，因此即使BoilerplateJS组件没有主动显示其内容，用户也可以在页面上使用其他信息。我们在组件上呈现了一些错误信息，并提供了重新登录的链接。

Since we did not redirect, user was able to make use of other information on the page even the BoilerplateJS component was not actively displaying it's content. We had a rendered some error information on the component with a link to re-login.

通过我们创建的通用错误处理程序完成此操作。从component.js，我们将错误回调函数传递给我们的viewmodel（你也可以在上下文中使用它）。 viewmodel使用此回调函数来通知其中发生的任何错误。在401 HTTP代码的情况下，调用此处理程序，要求component.js呈现具有错误信息的UI和重新登录的链接。

Handling of this was done via a generic error handler we created. From component.js, we pass a error callback function to our viewmodel (you may have this on context itself too). This callback function is used by the viewmodel to notify any error occurred within it. In the case of 401 HTTP code, this handler is invoked asking component.js to render UI with error information and a link to re-login.

用户点击在重新登录URL上返回登录页面。此URL包含对原始URL的反向引用，以便用户能够访问身份验证后的页面。

User clicks on the re-login URL to get back to the login page. This URL contains a back reference to the originated URL, such that user is able to get to the page where he was after authentication.

这篇关于BoilerplateJS：处理授权和身份验证的推荐方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！