当我使用Backbone和AMD模块时,哪里有存储授权数据的最佳位置?

时间:2012-01-22 18:25:47

标签: javascript backbone.js amd

我为注册用户或非注册用户创建了带Backbone和RequireJS的js应用程序。要从数据库中检索数据,我使用简单的JSON Web服务,当然有些方法不适用于任务。问题是我不知道在没有在每个视图中重新加载的情况下我应该从服务器存储auth数据的位置或方式。我应该使用cookies吗?

1 个答案:

答案 0 :(得分:6)

我想这取决于您的身份验证,授权方法以及您需要为用户考虑的安全类型。如果您尝试使用RESTful,则无法使用会话来保存状态(至少是服务器端)。你可以,但由于保存服务器上的状态,它不会是RESTful,如果这对你很重要。我听说保存状态客户端是可以的,但是从我读过的内容来看,我不确定社区对采用这种方法的某些实现的感受。 (像饼干一样,我稍后会再次访问。)

假设您有人使用用户名和密码登录。您可以在Backbone应用程序中保存该信息,也许您有一个名为AUTH的模型可以执行此操作。每次向服务器发出请求时,您都会在每次旅行时发送该数据,此时服务器进行身份验证并提供或拒绝访问给定资源。如果你使用Basic Auth,这个信息将在我认为的标题中。使用SSL减轻了围绕通过网络发送此信息的一些主要安全问题,并且对于其余的讨论,我们假设这是我们正在使用的。

您可以这样做的另一种方法是使用加密的cookie,加密的cookie会话。这就是我对当前应用程序的处理方式。老实说,我不知道这是否被视为违反RESTful原则。网上的一般喋喋不休似乎是很多“饼干坏,会话不好”,有些人说,“变得真实”。如果某人有权访问用户计算机,使用cookie会使您遭受cookie劫持,但根据您的应用程序和安全需求,它可能不是一个不合理的选择。它适用于我,如果它不是RESTful,我喜欢称之为RESTLike。

要关闭我只会描述我的设置。很高兴得到你的想法以及Stack对此的看法。

基本上我有一个设置,当有人进入主页面时,服务器会检查加密的cookie会话。如果cookie会话无效或不存在,则会为用户提供有登录机会的常规页面。当他们登录时,我通过POST发送该信息,因此它位于请求的主体而不是URI中。 (这在技术上违反了REST HTTP动词概念,因为您使用POST来保存资源。)处理该信息时,检查用户名,传递由唯一salt创建的哈希,然后服务器创建加密的会话cookie并通过它回到用户。现在,每次我的用户点击需要身份验证的路由时,服务器都会检查cookie以确保它仍然有效(时间限制,用户信息等),如果是,则允许访问。如果没有,它会破坏cookie信息并发回适当的状态代码。骨干应用程序通过重置任何不应由未经身份验证的用户手中的视图和数据来对此做出反应,并向他们显示登录屏幕。

希望这会给你一个想法。这就是我如何做到这一点的答案,但如果有人有批评或更好的想法,我会乐意向他们投票。