I just started writing my ember app and i’m having problems structuring the base routes. My application needs to be protected by a login page that is presented to the user if they are not authenticated. This /login route shouldn’t contain any of the navigation, footers, and side-menu’s that are present in the rest of the whole application. I started off by adding all of those components to the application.hbs which is cool because it is rendered with every route. But for the /login route and potentially any other unauthorized user routes this isn’t the case.
The way we approached this problem in our app was to define two top-level resources to represent the two different layouts. One for all secured pages, and another for the unsecured login page.
Stand clear from resource(), for its fate is sealed and neck’s already on chopping block.
Resources allowed you to nest themselves, they also had some extra magic in how their names are handled in neesting (ergo ‘comments’ resource nested within ‘post’ resource was accessible via {{link-to "comments"}} instead of {{link-to "posts.comments"}} (same rule stood for routes/controllers classes implemented for those).
Howefect you can nest routes as well for some time now, and arguably namespace resetting isn’t that much of game changes for devs to keep resource around anymore.
This may be stupid, but works for me. One simple if statement in application.hbs like {{#if isAuth}}… else {{ render ‘login’}} and this is for ember 1.10.0
Authentication as a session property extending controllers and routes, such as the standard for simple-auth and torii. Set a boolean like “isAuth” for when a session is authenticated.
Thus on index route:
redirect: function() {
if (!this.get('session.isAuth')) {
this.transitionTo('login');
}
}
and something similar in index.hbs, so that the index route of myapp.com shows a welcome/login page for unauthed users, and a “home” page for auth’d users (like twitter, fb, etc.)