Ember-simple-auth: Deprecation message in tests

Created on 17 May 2017  Â·  5Comments  Â·  Source: simplabs/ember-simple-auth

Recently I have started receiving this deprecation [deprecation id: ember-simple-auth.configuration.routes] in my tests

I have such options in config

'ember-simple-auth': {
        authenticationRoute: 'login',
        routeAfterAuthentication: '/',
        routeIfAlreadyAuthenticated: '/',
},

To fix this deprecation do I need to specify this fields for all routes which are use corresponding mixins? As for me its too many duplications or am i missing something?

question

Most helpful comment

Yes, if you have a lot of individual routes that all use the AuthenticatedRouteMixin you'd have to do that. Although you can of course create your own mixin that implements the AuthenticatedRouteMixin and sets the properties accordingly:

import AuthenticatedRouteMixin from 'ember-simple-auth/mixins/authenticated-route';

export default Ember.Mixin.create(AuthenticatedRouteMixin, {
  authenticationRoute: 'whatever'
});

Usually the best option is to nest all authenticated routes under a common parent route so that you don't have to repeat any of the logic, e.g.:

this.route('auth', function() {
  // all of your app's routes that require authentication
});

You should even be able to use a route with an empty path as the common parent route so that your users won't recognize the additional route:

this.route('auth', { path: '' }, function() {
  // all of your app's routes that require authentication
});

All 5 comments

Yes, if you have a lot of individual routes that all use the AuthenticatedRouteMixin you'd have to do that. Although you can of course create your own mixin that implements the AuthenticatedRouteMixin and sets the properties accordingly:

import AuthenticatedRouteMixin from 'ember-simple-auth/mixins/authenticated-route';

export default Ember.Mixin.create(AuthenticatedRouteMixin, {
  authenticationRoute: 'whatever'
});

Usually the best option is to nest all authenticated routes under a common parent route so that you don't have to repeat any of the logic, e.g.:

this.route('auth', function() {
  // all of your app's routes that require authentication
});

You should even be able to use a route with an empty path as the common parent route so that your users won't recognize the additional route:

this.route('auth', { path: '' }, function() {
  // all of your app's routes that require authentication
});

I'm sorry to resurrect this issue, but I thought I'd offer some feedback as a new user. This deprecation warning is really confusing, made more so by some missing docs in the README for how to handle these values.

It's unclear as to where these values go. With the old, configuration-based solution, it was clear where these values went (and the above issue doesn't exist). It'd be really nice to have a clear example of the usage of these configurations, and recommended structure for making this sane — even a naive solution.

Here's what I'm currently doing (perhaps in working through this I can submit a PR to update the README):

  1. My index route attempts to redirect a user to some authenticated route. There is no special ESA configuration in this route.
  2. My authenticated routes are nested under and "auth" route (per your comment above). This route configures the authenticationRoute, routeIfAlreadyAuthenticated, and routeAfterAuthentication.
  3. My unauthenticated routes configure routeIfAlreadyAuthenticated and routeAfterAuthentication (side note: it's not clear if I need to do a manual transition after authentication from the docs, it's only clear after playing with the addon that this isn't needed).

Is that pretty much correct? I feel like it cannot be given that my acceptance tests fail inconsistently with respect to authentication routing.

An addendum to this is that it seems like if we want to configure all of these values on the routes, it ought to be on the application route. Heck... I'm not really sure moving these configuration values out of the config file makes sense in the first place.

I think (hope 😜) I addressed some of your concerns in #1526. I think instead of adding extensive info on this topic to the already pretty long README it'd be great to have a guide on customizing ESA. If you'd be willing to prepare one that'd be 🎉

Yeah, I'd love to! I'll try to write something up this week and submit a PR.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lucasm-iRonin picture lucasm-iRonin  Â·  10Comments

john-griffin picture john-griffin  Â·  4Comments

st-h picture st-h  Â·  6Comments

romulomachado picture romulomachado  Â·  6Comments

adc-mhaugen picture adc-mhaugen  Â·  3Comments