Authentication lifecycle support



Since most applications need some authentication support it doesn’t make sense to make users find their own path how to handle it and I find myself repeating the same code for handling client side authN,

If you are not against this then the highlights I was thinking about are:

  1. Provide some authN token based support by managing the authN flow but with some freedom (See below)
  2. Expect a promise of the login action to the server, implemented by the user.
  3. Raise authenticationRequired event when error code (default to 403) occur but let the user choose other codes (such as 401) to suite custom needs, this is a generic but easy way to redirect to the login form or any other route that needs to take care of authentication.
  4. Store credentials in localStorage but let user overrides this easily for custom needs(cookie based maybe)
  5. Support even credentialsHasChanged in case user re-authenticate

If there’s a good reason to totally not support anything related to authN then feel free to close the issue, if you are up to it then comments are welcome to understand whether this is possible to generalize enough to support any user needs but still provide some value out of the box.



hey @asaf000, I totally agree with you, that it could be a great additional value, if Ember.js provides some standard way of authentication so that this task could be easily achieved. As I read through your post, some things are not totally clear to me:

why would you choose authN as “standard” authentication implementation (regarding that you mean:

would you really store the user credentials in localStorage or do you mean the authentication token?

which implementation would you choose? Controller? I personally like it more to have it as a util class/component which is accessible throughout the whole application (acutally I’m working with User and UserManager classes in my application(s))


@herom thanks for the feedback,

By “standard” I believe Ember should provide a token based authentication flow as this is the standard nowadays,

Regarding localStorage, I believe that this should be the standard way to store the token, exactly but still gives the user a possibility to provide his own store/fetch methods to override standard behavior,

IMO there should be a ‘authenticationController’ because:

  1. There is a form based authentication in most apps and binding form properties to Controller makes sense,
  2. Controllers are available through the app easily, especially when server side calls should happen through Controllers & Routes mainly and both can access the controller very easily but a manager make sense too.

I really hope to see someone from the core team to give us some feedback too,




For what it’s worth, I +1 this.

As stated by the OP, authentication is a really common and basic task that you would want to achieve in most nowadays web applications. The information on how to implement it is really sparse, everybody has their opinion and it’s more complex than it should.

I really hope this gets addressed.


Have a look at EmberSimpleAuth. It does exactly this. I’m using it and it works like a charm!