随着BoilerplateJS的设置,推荐的处理授权和认证的方式是什么?BoilerplateJS:处理授权和认证的推荐方式
很显然,在服务器端你会检查cookies等以知道谁登录了。但是,在客户端,你如何知道用户是否登录以及他们的用户名等等是什么?
随着BoilerplateJS的设置,推荐的处理授权和认证的方式是什么?BoilerplateJS:处理授权和认证的推荐方式
很显然,在服务器端你会检查cookies等以知道谁登录了。但是,在客户端,你如何知道用户是否登录以及他们的用户名等等是什么?
我将分享如何在使用BoilerplateJS的其中一个项目中完成这项工作。在这个项目中,我们使用OAuth 2.0进行身份验证。
我们有一个单独的登录页面,它不使用BoilerplateJS或复杂的JS。保持独立的原因是验证可能取决于URL重定向,而JS不能最好地处理。
一旦用户被正确验证,我们会收到服务器会话的auth_token并将其存储为JS变量。我们使用全局Boiler.Context的'设置'来存储这个令牌。由于设置被继承到子上下文,我们可以从任何地方访问它。
为了进行授权,我们然后下载了一个包含授权访问密钥的记录用户的简单ACL。这些键仅用于客户端验证以显示/隐藏控件。真正的授权是在后端服务上执行的。
我们希望BoilerplateJS组件完全自包含,包括验证它。因此,如果特定组件的视图模型从服务器接收到未经授权的401 HTTP响应(未登录或会话终止),则我们在此处呈现组件,而不将用户重定向到登录页面。
由于我们没有重定向,用户可以利用页面上的其他信息,即使BoilerplateJS组件没有主动显示它的内容。我们在组件上显示了一些错误信息,并提供了重新登录的链接。
这是通过我们创建的通用错误处理程序完成的。从component.js中,我们将错误回调函数传递给我们的视图模型(您也可以在上下文中使用它)。视图模型使用此回调函数来通知其中发生的任何错误。在401 HTTP代码的情况下,调用此处理程序,要求component.js呈现带有错误信息和重新登录链接的UI。
用户单击重新登录URL返回登录页面。该URL包含对始发URL的反向引用,以便用户能够进入认证后的页面。
如果您在服务器端使用cookie,为什么不在客户端使用它们? –
如果我正确理解了ASP .NET Forms Authentication,那么这个cookie就会被加密 - 在客户端上有解密cookie的代码会使应用程序变得脆弱。 – georgiosd