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?
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):
authenticationRoute, routeIfAlreadyAuthenticated, and routeAfterAuthentication.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.
Most helpful comment
Yes, if you have a lot of individual routes that all use the
AuthenticatedRouteMixinyou'd have to do that. Although you can of course create your own mixin that implements theAuthenticatedRouteMixinand sets the properties accordingly: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.:
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: