令牌认证与Cookie [英] Token Authentication vs. Cookies
问题描述
我正在尝试实现 Ember Auth Rails演示，但是我不明白背后使用令牌认证的原因，如 Ember Auth FAQ 关于为什么进行令牌验证的问题？
典型的wep应用程序大多是无状态，因为它是请求/响应性质。 HTTP协议是无状态协议的最佳示例。但是由于大多数网络应用程序需要状态，为了保持状态，服务器和客户端之间使用cookies，以便服务器可以将每个响应发送回客户端。这意味着从客户端发出的下一个请求将包含该cookie，因此将被服务器识别。这样，服务器可以使用无状态客户端维护会话，主要了解应用程序的状态的所有内容，但存储在服务器中。在这种情况下，客户端不会持有状态，而不是 Ember.js 工作。
在Ember.js中，事情是不同的。 Ember.js使程序员的工作更容易，因为它确实为您确定了状态，在客户端，每一刻都知道它是状态，而无需向服务器要求状态数据。
然而，在客户端中持有状态也可能会引入并发问题，根本不存在于无状态情况。 Ember.js，但是也为您处理这个问题，具体来说，ember数据是考虑到这一点的。总之，Ember.js是为有状态客户端设计的框架。
Ember.js不像典型的无状态 Web应用程序，其中会话，状态和相应的Cookie几乎完全由服务器处理。 Ember.js在javascript中（在客户端的内存中，而不是DOM像其他框架中）完全保持状态，并且不需要服务器来管理会话。这导致Ember.js在许多情况下更为通用，例如当您的应用程序处于离线模式时。
显然，出于安全考虑，它确实需要某种标记或唯一键要发送到服务器，以便要求认证，这样服务器可以查找发送令牌（最初由服务器发出），并在发送前验证其是否有效
在我看来，使用认证令牌而不是Cookie的主要原因如 Ember Auth FAQ 主要是因为Ember.js框架的性质，也是因为它更适合于有状态的网络应用范例。因此，在构建Ember.js应用程序时，cookie机制不是最好的方法。
希望我的答案能给您更多的意见。
What is the difference between token authentication and authentication using cookies?
I am trying to implement the Ember Auth Rails Demo but I do not understand the reasons behind using token authentication as described in the Ember Auth FAQ on the question "Why token authentication?"
A typical wep app is mostly stateless, because of it's request/response nature. The HTTP protocol is the best example of a stateless protocol. But since most web apps need state, in order to hold the state, between server and client, cookies are used such that the server can send in every response back to the client. This means the next request made from the client will include this cookie and will thus be recognized by the server. This way the server can maintain a session with the stateless client, knowing mostly everything about the app's state, but stored in the server. In this scenario at no moment does the client hold state, which is not how Ember.js works.
In Ember.js things are different. Ember.js makes the programmer's job easier because it holds indeed the state for you, in the client, knowing at every moment about it's state without having to make a request to the server asking for state data.
However, holding state in the client can also sometimes introduce concurrency issues that are simply not present in stateless situations. Ember.js, however deals also with this issues for you, specifically ember-data is built with this in mind. In conclusion Ember.js is a framework designed for stateful clients.
Ember.js does not work like a typical stateless web app where the session, the state and the corresponding cookies are handled almost completely by the server. Ember.js holds it's state completely in javascript (in the client's memory, and not in the DOM like some other frameworks) and does not need the server to manage the session. This results in Ember.js being more versatile in many situations, e.g. when your app is in offline mode.
Obviously for security reasons it does need some kind of token or unique key to be sent to the server everytime a request is made in order to be authenticated, this way the server can lookup the send token (which was initially issued by the server) and verify if it's valid before sending a response back to the client.
In my opinion the main reason why to use an authentication token instead of cookies as stated in Ember Auth FAQ is primarily because of the nature of the Ember.js framework and also because it fits more with the stateful web app paradigm. Therefore the cookie mechanism is not the best approach when building an Ember.js app.
I hope my answer will give more meaning to your question.
这篇关于令牌认证与Cookie的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
