Ember.js cookie based authentication with Rails and development

Question

I am looking to satisfy 3 goals with my authentication in Ember.js using rails, development and cookie based session.

• Redirected to #/sessions/new if they are not logged in.
• Always show current user information in the application template.
• If the user is logged in and he goes directly to #/some/route . The current user must be logged in at boot time.

I watched these videos with embercast: Client Side Authentication Part 1 and Client Side Authentication Part 2 . They are a bit outdated, but useful.

But still there can be no complete solution. Does anyone have full Rails 4, Devise, Emberjs 1.0.0?

The biggest problem is the strategy of loading the current user to load the page and setting the current user when submitting the form.

Now this is my strategy:

 App.User = Em.Object.extend(); App.User.reopenClass({ current: function() { return Ember.$.getJSON("/users/current").then(function(data) { return data }) } }); App.ApplicationRoute = Ember.Route.extend({ model: function() { return App.User.current(); } }); App.SessionsNewController = Ember.ObjectController.extend({ actions: { save: function(data) { var self = this, data = this.getProperties('email', 'password'); $.post("/sessions", { session: data }).always(function(response, status, data) { if (status == "success") { self.transitionToRoute('index'); } else { self.set('errorMessage', data); } }) }, } }); 

Answer 1

I would not say that this is impossible. But you will do a lot of unnecessary and unnecessary work to make authentication work, which can be done with a simple page redirect.

I gathered some opinions from Derick, author of Backbone.Marionette. Although this is for Backbone, but not Ember.js, the situation with client-side authentication is the same.

It seems sick and unnecessary to try to get Backbone / Marionette to process authentication and reloading an authorized site. After they log in, redirect them to another URL that the server processes, and ask the server to send all the things they need as an authenticated user. fooobar.com/questions/956122 / ...

Another quote from Derick:

Right And in many cases, when I just say, “Don't do single-page apps.” And the login screen is the biggest example of this. For all the clients that I had over the past couple of years, they all asked me: “Hey, I have this problem. I'm trying to get my login screen to return me the current user information from the server and repeat all this material on the screen, without updating everything. " My answer every time: "Do not do this." http://javascriptjabber.com/056-jsj-marionette-js-with-derick-bailey/

Also think about other cases, say Gmail. You won’t get a smooth transition after clicking the “Login” button on the Gmail login page. It will also be redirected with a rather large data load :)

From the point of view of users, they will not say that Gmail is small only because there is a redirect after logging in. After signing / registering is much less common than daily postal operations.

So my suggestion is to reload all resources after changing user session. Let Rails and Devise do the dirty work in the traditional way.