当我使用 Backbone 和 AMD 模块时，存储授权数据的最佳位置在哪里？
我使用 Backbone 和 RequireJS 为注册或非注册用户创建 js 应用程序。为了从数据库检索数据，我使用简单的 JSON Web 服务，当然有些方法不可用于查询。问题是我不知道应该在哪里或如何存储从服务器检索的身份验证数据，而无需在每个视图中重新加载它。我应该使用cookie吗？
I create js app with Backbone and RequireJS for registred or non registred users. To retrive data from database I use simple JSON web service and of course some of methods are not avaiable for quest. Problem is that I don't know where or how I should store auth data retrive from server without reloading it in every view. Should I use cookies ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想这取决于您的身份验证、授权方法以及您需要为用户考虑的安全类型。如果您尝试实现 RESTful，则无法使用会话来保存状态（至少在服务器端）。你可以，但由于状态保存在服务器上，它不会是 RESTful 的，如果这对你很重要的话。我听说可以在客户端保存状态，但从我读到的内容来看，我不确定社区对采用这种方法的某些实现有何看法。 （就像 cookie 一样，我稍后会重新讨论这一点。）
假设有人使用用户名和密码登录。您可以在 Backbone 应用程序中保存该信息，也许您有一个名为 AUTH 的模型可以执行此操作。每次向服务器发出请求时，您都会在每次行程中发送该数据，此时服务器会进行身份验证并授予或拒绝对给定资源的访问权限。如果您使用基本身份验证，我认为此信息将位于标头中。使用 SSL 可以减轻围绕通过线路发送此信息的一些主要安全问题，在讨论的其余部分中，我们假设这就是我们正在使用的。
另一种方法是使用加密的 cookie、加密的 cookie 会话。这就是我对当前应用程序所做的事情。老实说，我不知道这是否被视为违反 RESTful 原则。网络上的一般讨论似乎有很多“cookie 不好，会话不好”，有些人说“说实话”。如果有人有权访问用户的计算机，则使用 cookie 会使您面临 cookie 劫持，但根据您的应用程序和安全需求，这可能不是一个不合理的选择。它对我有用，如果它不是 RESTful，我喜欢称其为 RESTlike。
最后，我将仅描述我的设置。如果能了解您的想法以及堆栈对此的看法，那就太好了。
基本上我有一个设置，当有人进入主页时，服务器会检查加密的 cookie 会话。如果 cookie 会话无效或不存在，它会为用户提供登录常规页面的机会。当他们登录时，我通过 POST 发送该信息，因此它位于请求正文中而不是 URI 中。 （从技术上讲，这违反了 REST HTTP 动词概念，因为您使用 POST 来保存资源。）处理该信息时，检查用户名，传递由唯一盐创建的哈希值，然后服务器创建一个加密的会话 cookie 并传递它返回给用户。现在，每次我的用户点击需要身份验证的路由时，服务器都会检查 cookie 以确保它仍然有效（时间限制、用户信息等），如果有效则允许访问。如果没有，它会销毁 cookie 信息并发回适当的状态代码。主干应用程序对此做出反应，重置任何不应由未经身份验证的用户掌握的视图和数据，并向他们显示登录屏幕。
希望这能给你一个想法。这是我如何做到这一点的答案，但如果有人有批评或更好的想法，我很乐意为他们投票。
I guess it depends on your authentication, authorization methods as well as the kind of security you need to consider for your users. If you're trying to be RESTful, you can't have sessions to save state (at least server-side). You could, but it wouldn't be RESTful due to saving of state on the server, if that matters to you. I've heard that it is okay to save state client-side but from what I've read, I'm not sure how the community feels about certain implementations that take this approach. (Like cookies, I'll revisit this later.)
Say you have someone login with username and password. You can hold that information in your Backbone app, maybe you have a model called AUTH that does this. Each time you make a request to the server you'd send that data each trip at which point the server authenticates and gives or rejects access to given resources. If you use Basic Auth this information would be in the header I think. Using SSL mitigates some of the major security concerns surrounding the sending of this information over the wire and for the rest of the discussion let's assume this is what we are using.
The other way that you could do this is to use encrypted cookie, encrypted cookie sessions. This is what I do with my current application. Honestly, I don't know if this is considered a violation of RESTful principles or not. The general chatter on the web seems to be a lot of "cookies bad, sessions bad" with some people saying, "get real." Using cookies would expose you to cookie hijacking if someone had access to the users computer, but depending on your application and the security needs it might not be an unreasonable option. It works for me and if it isn't RESTful, I like to call it RESTLike.
To close I'll just describe my setup. It would be nice to get your thoughts as well as the Stack's opinions on this also.
Basically I have a setup where when someone goes to the main page, the server checks for the encrypted cookie session. If the cookie session is invalid or non-existent, it gives the user the regular page with a chance to login. When they login, I send that information over POST so it's in the body of the request rather than the URI. (This is technically a violation of the REST HTTP verb concept since you use POST to save a resource.) When that information is processed, check the username, pass hash created by a unique salt, then the server creates an encrypted session cookie and passes it back to the user. Now, each time my user hits a route that requires authentication, the server checks the cookie to make sure it is still valid (time limit, user information, etc.) and if so - allows access. If not, it destroys the cookie information and sends back an appropriate status code. The backbone app reacts to this by resetting any view and data that shouldn't be in the hands of an unauthenticated user and shows them the login screen.
Hope this gives you an idea. This is the answer to how I do it, but if someone has criticisms or better ideas I'd be happy to upvote them instead.