This course has been updated! We now recommend you take the API Design in Node.js, v4 course.
Transcript from the "Testing the Authentication" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Scott Moss: So, let's check and see if that works. So, first we'll do let's just go get a user from c, we'll use this person, we'll grab their user name, all the passwords are test. So, I come over here and say http and POST, to sign up, localhosts:3000/auth, right?
[00:00:26] /auth because if you go to server js, /auth, right there, /auth. And then if you go to that, /signin, so /auth, /signin.
>> Scott Moss: /auth/signin, right? And then what you wanna do is post your username= that and then password=test. There we go and then we get a token back.
[00:01:07]
>> Scott Moss: See how that works? If you look at the logs in the server, we got a successful 200. So, okay, yeah, yeah that worked. Everything works. We're good. All right. Now if I change it, if i was like, okay let me try to sign in again but, I'm gonna put the wrong password in.
[00:01:23] All right, so what I expect to see if I, I've got so many things open, what I expect to see with the wrong password, is this. I should see wrong password. That's what I should see. Because what would happen is, the verify token would work or the decode token would work, so that, I'm sorry we're not using tokens, never mind.
[00:01:44] Let's do it to iron. So, what will happen is there is a username and password so to skip this, it will find the user by the username which is correct cuz we give it the right username. This will never happen because there is a user, so it will come down here and then this is where it fell.
[00:01:58] It like, woah those two passwords don't match. So, because of that expect to see this. So let's check that. So wrong password, there it is, wrong password.
>> Scott Moss: And then if I also decided to do it with no password and no user name, I expect to see, you need a username and password.
[00:02:21] And that's exactly what I see. Is there another s case? Yeah. Now if I give it the wrong username but the right password or any password. Let's just give it a completely wrong username. I should see, no user with the given username. So I see that, no user with the given username.
[00:02:47] Everybody follow me there? Any questions on this stuff? Yes?
>> Speaker 2: What are benefits to using Passport versus doing it manually this way? And then he's saying if, he didn't know if you had time, but could you show how to switch out the custom middleware with Passport js?
>> Scott Moss: Yeah, Passports, so there's a little more overhead with Passport, but for good reasoning.
[00:03:08] If I were to build my own, I would probably use Passport, because these days, most applications have third party Or with sign ins with third party providers like Facebook or Twitter. Yourself is doable, but if you're not familiar with how OF works and all the double handshake and all that stuff works and all that good stuff.
[00:03:28] You probably would use something like Passport. So, if you're only doing a local sign up, like we're doing now, maybe Passport doesn't seem like it's worth the overhead. But if you probably have more than one strategy as far as authentication. So, Passport actually, it's like you write it once and then it just has diminishing returns on how hard it is to add another feature to it cause it's the same thing.
[00:03:47] As far as having time, we if we have time at the end, I have some stuff I want to get to, we could get to that, cause it's not too difficult, but the only difference with Passport and this one. In my opinion there's gonna be a lot more overhead with Passport but it's literally doing the same thing.
[00:04:02] You're still gonna do, in fact, you probably will just copy this, this whole method right here, and paste it in Passport. It'll do the exact same thing. The only thing you do differently is instead of calling next, you just have to call you just have to tell password that you're done.
[00:04:17] That's it. And then you had to we also had to disable sessions cuz Passport use a sessions by default. And they don't work they don't obviously we're not using sessions. So, whether to disable that. So, just little more overhead just for one strategy, but for multiple strategies, it's out for the best and if I had to do it, I would use Passport
[00:04:36]
>> Scott Moss: Any other questions?
>> Speaker 2: He was asking about if you could show how to switch that out, but if you don't have time for today maybe you could push it to the repo later?
>> Scott Moss: Yeah, if I don't have time to show it today, I will definitely push it to the repo, and we'll have it.
[00:04:46] I'll probably even add in another strategy, so that you can like click to log in with Facebook or something like that. So, you can see how that works. Yes.
>> Speaker 3: If you grant another token, does that kill the old token? Or are they both still valid?
>> Speaker 3: So let's say you post a sign in, you get a token.
[00:05:06]
>> Scott Moss: Mm-hm.
>> Speaker 3: Then you post a sign in again and you get another token.
>> Scott Moss: Right.
>> Speaker 3: If you tried to access a resource with that other token that's still valid right, it's not like there's only one valid token at a time?
>> Scott Moss: Right, because the service all it knows, it doesn't keep track of tokens.
[00:05:22]
>> Scott Moss: It just knows if you give me this token, that was signed with this secret. I guarantee you I will give you what it used to be before it was signed. That's it. And if it's not expired.
>> Speaker 3: Okay.
>> Scott Moss: So yeah, you can have more than one token.
[00:05:38] So if I like, made this token, and then I made this token, they're both valid tokens. I could use either one of these for this user, so they'll get my stuff. And it would work.
>> Speaker 3: So if someone gets your secret, they could extend the life of a token, right?
[00:05:51]
>> Scott Moss: If somebody gets your token secret You have bigger problems than extending the life of it, but yeah.
>> Speaker 3: Yeah, okay.
>> Scott Moss: That's why they expire, because what's stopping you from just making a JSON web token and posting to my database, and acting like the user.
>> Speaker 3: I don't know.
[00:06:06]
>> Scott Moss: Yeah, there's nothing until you expire them. So you gotta have a secret and stuff, so have those things expire.
>> Speaker 2: So, people underneath use redis for authentication? Restore sessions.
>> Scott Moss: No, I don't use sessions. But if you were to use sessions, redis is a great choice. So, a simple key value store, perfect for things like sessions.
[00:06:27] But I don't use sessions.
>> Scott Moss: Cool. Any other questions on that? It's kind of crazy how it all works together, right? It almost feels like there's no way that's gonna come together at the end and then somehow it just comes together. That's how I feel sometimes. But yeah, it just came together.
[00:06:53] But it makes sense. If you walk through it and you look at the things that it's checking for, it makes sense, it's not like there's something hidden, well except for this thing.
>> Speaker 3: [LAUGH]
>> Scott Moss: That thing's kinda hidden. But, I told you what that's doing, everything else it's just like it's in plain in sight what's happening.
[00:07:12] Course the next thing you had to do was,
>> Scott Moss: If you didn't do this, this is fine, because we didn't use it in this example. So, if you didn't feel comfortable writing this because there's no way to even test it, that's fine, cuz we're gonna use it on step 12.
[00:07:24] But I wanted you to write it to get ready to use in step 12, but if you didn't do it, that's fine. We're gonna use it on step 12. So this method, get fresh user, like I said, it's job is to get a fresh user because when we decode the token all we have is the ID, the auto-square ID, we actually want the entire user.
[00:07:44] So, by the time our controllers are called, they can just say, hey I want to know who the current user is and if they look at rec.user, that'll be then the entire user object, not just the ID property. That way they don't have to do another database query on top of the query they're about to do in the first place, right?
[00:08:00] It's already done. So, that's all this is doing, is just like querying the database for this thing. So here's the S case of like somebody sending us a token that passes our validation because it was signed with the same secret and everything, but for some reason there doesn't exist a user with that ID in our database.
[00:08:20] So we're like nope, you're unauthorized. You did everything right except for the IDs just don't match. Else, req.user is user, so it's almost pretty simple and just calling next.
>> Scott Moss: Any questions on that one? And we're not using it anywhere so if you're like, where are we using the We're not using it yet
[00:08:49]
>> Scott Moss: Greats great great,
>> Scott Moss: I think that was all you had to do
>> Scott Moss: Yeah yeah, that was all you had to do. So, knowing that, is there any questions around authentication? As far as JSON web tokens, as far as the passwords, how we do that, as far as Mongo and Mongoose using these schema methods or there prehooks, anything surrounding that?
[00:09:21] I want to make sure we answer that stuff now before we start moving in, cuz we gonna start moving in to a little more abstraction. So, I wanna make sure everybody is on a good understanding of things that might be confusing.