Guarded Login & Team Routes

[00:00:00]
>> Mike North: Next, we're going to extend on this service we've just built. By making it so that only logged in users make it into the teams page, and only logged out users can make it to the login page. And we're gonna do this using Ember's route and hooks that are available for us to customize there.

[00:00:20]
So let's look at the two routes we created earlier in the course. One was called teams, one was called login. And these are those jazz files that are in the app/routes folder.
>> Mike North: Here we go. There's nothing interesting here at this point, and what we need to do is understand there is a cycle of functions that these routes invoke, and these give us a convenient customization points to use.

[00:00:54]
One, which we're gonna use, I think it's in the next step or the step after that. It's the model hook, and this is typically what's used to fetch data. So whatever this hook returns, we're gonna be able to use in this route template pretty easily. We want to validate whether the user's authentication state is good or bad for a particular URL before this model hook is called.

[00:01:24]
So there's another hook and it's called before model.
>> Mike North: And this is a terrific place to validate entry of a particular route. Because this is a hook, it's a method on the base class where you are customizing, we wanna call it the super method in order to ensure that it has a chance to do everything that it might do.

[00:01:54]
I don't want anyone to worry too much about what the default behavior is, in this case it's not much, but if you always call super, you're unlikely to have a bad time. If you try to prematurely optimize and strip this out thinking that nothing's there, nothing's there, we could introduce something in the future, and now you're missing it, and bad things happen, and it could be confusing.

[00:02:20]
I also wanna point out that before model, model, and after model, those route hooks are promise aware. What that means is as the route does its thing and it starts loading data and doing everything that this route is designed to do, in the event that these functions return promises it will wait for those promises to resolve.

[00:02:45]
Does this sound like any kind of now core JavaScript language feature that exists?
>> Speaker 2: The asynchronous functions.
>> Mike North: Async functions, so we can actually define this as async functions, and that lets us do something like a wait super before model. And I'm getting, let's see, yes. So we have to pass arguments, in this case there's transition, that's the only argument that before model gets.

[00:03:19]
And a transition, it's just an object that let's you, you could abort a transition, we're not gonna worry too much about that, but if you wanted a very rich login experience you could actually kick a user out to the login page. And then once they successfully log in you can send them back to the original URL they had tried to access.

[00:03:40]
This would all be done via aborting the transition and retrying. It's just a little atom of state that we use that represents the attempt to get into this URL. We just need to pass it straight through in this case here. So the next thing we wanna do is we need authentication, we need to know about that.

[00:04:06]
We need to know whether the current user ID is there or not. And how would we accomplish this? Any ideas?
>> Speaker 3: Service.
>> Mike North: Service, we gotta inject the service. So import ( inject as service ) from Ember/service, and down here we'll say service auth.
>> Mike North: Yeah, we can keep that around, that's a nice import.

[00:04:38]
>> Mike North: That will be a good JS dot thing, type AuthService.
>> Mike North: Now we just simply need to say if this.auth,
>> Mike North: currentUserId, and this is the team's route. So I actually want this function to sort of almost be a no op if the current user ID is defined.

[00:05:11]
So if it's undefined, if it's I'm gonna say this TransitionTo login.
>> Mike North: So this basically says do the default stuff that Ember might do for before model. If the currentUserId is falsely, kick them out to the login page. They'll never actually make it to the chat UI. Let's experiment and see if this works.

[00:05:42]
Okay, so I'm on the teams page. Logout is not wired up yet, we'll do that in a moment. I can imitate logout by just deleting this from my local storage. Guess I have to click the delete, and now I wanna reload, despite being on /teams, and I find myself on the log in screen.

[00:06:05]
We've successfully kicked the user out, and I'm gonna copy this because we're gonna need basically the same thing for the login route, except we're just gonna flip the condition. Let me grab the imports in a second, but we just need to say look, if you are logged in you don't need the login form, we'll send you straight to teams.

[00:06:32]
>> Mike North: Let me grab those imports real quick,
>> Mike North: And we should be good to go. So now let me try to log in, which actually works, right? We're saving that, sign in, all right, and now let me try to go back to log in.
>> Mike North: Kicks me out to here.

[00:06:54]
Let me try deleting this. Refresh, delete, and we'll go back to login, and this should allow me to go through, and it does. So there we go, this is using a route hook to guard a route, to make it so that only under the right conditions should a user get in.