Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>A typical web app is mostly <strong>stateless</strong>, because of it's <strong>request/response</strong> nature. The HTTP protocol is the best example of a <strong>stateless</strong> protocol. But since most web apps need <strong>state</strong>, in order to hold the <strong>state</strong>, 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 <strong>session</strong> with the <strong>stateless</strong> client, knowing mostly everything about the app's <strong>state</strong>, but stored in the server. In this scenario at no moment does the client hold <strong>state</strong>, which is not how <a href="http://emberjs.com" rel="nofollow noreferrer">Ember.js</a> works.</p> <p>In Ember.js things are different. Ember.js makes the programmer's job easier because it holds indeed the <strong>state</strong> for you, in the client, knowing at every moment about it's <strong>state</strong> without having to make a request to the server asking for <strong>state</strong> data.</p> <p>However, holding <strong>state</strong> in the client can also sometimes introduce concurrency issues that are simply not present in <strong>stateless</strong> 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 <strong>stateful</strong> clients.</p> <p>Ember.js does not work like a typical <strong>stateless</strong> web app where the <strong>session</strong>, the <strong>state</strong> and the corresponding cookies are handled almost completely by the server. Ember.js holds it's <strong>state</strong> 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.</p> <p>Obviously for security reasons it does need some kind of <strong>token</strong> or <strong>unique key</strong> to be sent to the server everytime a request is made in order to be <strong>authenticated</strong>, 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.</p> <p>In my opinion, the main reason why to use an authentication token instead of cookies as stated in <a href="https://github.com/heartsentwined/ember-auth/wiki/FAQ" rel="nofollow noreferrer">Ember Auth FAQ</a> is primarily because of the nature of the Ember.js framework and also because it fits more with the <strong>stateful</strong> web app paradigm. Therefore the cookie mechanism is not the best approach when building an Ember.js app.</p> <p>I hope my answer will give more meaning to your question.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload