1 00:00:01,140 --> 00:00:03,050 ‫Let's now continue writing 2 00:00:03,050 --> 00:00:04,773 ‫our protect middleware function. 3 00:00:06,420 --> 00:00:08,910 ‫So in the last lecture, we read the token 4 00:00:08,910 --> 00:00:10,990 ‫from the authorization header 5 00:00:10,990 --> 00:00:14,080 ‫and then checked if the token actually exists. 6 00:00:14,080 --> 00:00:15,023 ‫So right here. 7 00:00:15,880 --> 00:00:19,890 ‫And next up, we have the verification step for the token. 8 00:00:19,890 --> 00:00:21,880 ‫And I hope you remember that in this step, 9 00:00:21,880 --> 00:00:24,520 ‫we verify if someone manipulated the data 10 00:00:24,520 --> 00:00:27,500 ‫or also if the token has already expired. 11 00:00:27,500 --> 00:00:31,840 ‫So we already used, from the JSON web token package, 12 00:00:31,840 --> 00:00:33,180 ‫the assign function function, 13 00:00:33,180 --> 00:00:35,623 ‫and now we're gonna use the verify function. 14 00:00:36,820 --> 00:00:39,333 ‫So just like before, jwt.verify, 15 00:00:43,000 --> 00:00:46,630 ‫and then in there, as you can imagine, we pass the token 16 00:00:46,630 --> 00:00:49,160 ‫so that the algorithm can read the payload 17 00:00:49,160 --> 00:00:52,133 ‫and then remember that this step also needs the secret. 18 00:00:53,250 --> 00:00:56,870 ‫So basically, in order to create the test signature. 19 00:00:56,870 --> 00:01:00,743 ‫So that secret is process.env.JWT_SECRET. 20 00:01:03,470 --> 00:01:04,610 ‫Remember that? 21 00:01:04,610 --> 00:01:05,860 ‫Now, as a third argument, 22 00:01:05,860 --> 00:01:09,003 ‫this function actually requires a callback function. 23 00:01:10,090 --> 00:01:12,180 ‫So this callback is then gonna run 24 00:01:12,180 --> 00:01:14,850 ‫as soon as the verification has been completed. 25 00:01:14,850 --> 00:01:16,840 ‫So you see that this verify here 26 00:01:16,840 --> 00:01:19,564 ‫is actually an asynchronous function. 27 00:01:19,564 --> 00:01:22,540 ‫So it will verify a token, and then after that, 28 00:01:22,540 --> 00:01:23,620 ‫when it's done, 29 00:01:23,620 --> 00:01:27,040 ‫it will then call the callback function that we can specify. 30 00:01:27,040 --> 00:01:29,910 ‫Now, we've been working with promises all the time, 31 00:01:29,910 --> 00:01:33,159 ‫and I don't really want to break that pattern here. 32 00:01:33,159 --> 00:01:37,000 ‫And so, we are actually going to promisifying this function. 33 00:01:37,000 --> 00:01:40,370 ‫So basically, to make it return a promise. 34 00:01:40,370 --> 00:01:42,660 ‫And so that way, we can then use async await 35 00:01:42,660 --> 00:01:45,613 ‫just like any other async function that we've been using. 36 00:01:46,820 --> 00:01:48,050 ‫So in order to do that, 37 00:01:48,050 --> 00:01:51,050 ‫Node actually has a built-in promisify function. 38 00:01:51,050 --> 00:01:53,650 ‫All we need to do in order to use it 39 00:01:53,650 --> 00:01:56,663 ‫is to require the built-in util module. 40 00:01:58,695 --> 00:02:00,895 ‫So let's do that right at the top, actually. 41 00:02:02,900 --> 00:02:07,900 ‫So that will create an object called util, require... 42 00:02:10,740 --> 00:02:13,400 ‫All right, so that stands for utility. 43 00:02:13,400 --> 00:02:15,420 ‫That's not what I wanted. 44 00:02:15,420 --> 00:02:16,960 ‫So that stands for utility. 45 00:02:16,960 --> 00:02:20,300 ‫And then on there, we are going to use the promisify method. 46 00:02:20,300 --> 00:02:22,900 ‫But since we're only going to use that one method, 47 00:02:22,900 --> 00:02:24,603 ‫we can actually do it easier. 48 00:02:25,578 --> 00:02:26,990 ‫So instead of doing this, 49 00:02:26,990 --> 00:02:30,610 ‫we can simply destructure that object 50 00:02:30,610 --> 00:02:32,823 ‫and take promisify directly from there. 51 00:02:35,388 --> 00:02:38,453 ‫So again, this is just using ES6 destructuring. 52 00:02:41,182 --> 00:02:43,230 ‫Okay, so and now it's very easy to use. 53 00:02:43,230 --> 00:02:46,127 ‫All we have to do is to actually call promisify. 54 00:02:47,434 --> 00:02:51,463 ‫So promisify, and then pass the function in there. 55 00:02:53,500 --> 00:02:56,080 ‫And so now, all this here is a function 56 00:02:56,080 --> 00:02:56,970 ‫that we need to call, 57 00:02:56,970 --> 00:02:59,190 ‫which will then return a promise. 58 00:02:59,190 --> 00:03:01,810 ‫So then here, we actually call the function. 59 00:03:01,810 --> 00:03:03,900 ‫And this will then return a promise, 60 00:03:03,900 --> 00:03:08,300 ‫and so we can await it and store the result into a variable. 61 00:03:08,300 --> 00:03:10,390 ‫So that result value of the promise 62 00:03:10,390 --> 00:03:12,350 ‫will actually be the decoded data, 63 00:03:12,350 --> 00:03:15,823 ‫so the decoded payload from this JSON web token. 64 00:03:17,600 --> 00:03:19,360 ‫So let me call it decoded here. 65 00:03:19,360 --> 00:03:20,193 ‫All right. 66 00:03:20,193 --> 00:03:23,490 ‫And we can do await because we actually already said 67 00:03:23,490 --> 00:03:25,453 ‫that it's an asynchronous function. 68 00:03:27,670 --> 00:03:30,850 ‫And now, just to see that it actually works, 69 00:03:30,850 --> 00:03:34,730 ‫let's log this decoded data to the console as well. 70 00:03:34,730 --> 00:03:38,143 ‫And actually, we can remove this console.log off the token. 71 00:03:39,050 --> 00:03:40,400 ‫That one we no longer need. 72 00:03:42,140 --> 00:03:46,560 ‫So let's try to send this request again, and yeah, 73 00:03:46,560 --> 00:03:49,990 ‫but this time actually turning on this authorization header 74 00:03:49,990 --> 00:03:54,850 ‫so that we send a JSON web token along with the request. 75 00:03:54,850 --> 00:03:55,940 ‫So that sent it. 76 00:03:55,940 --> 00:03:58,540 ‫And now, indeed, we get access to the data, 77 00:03:58,540 --> 00:04:02,070 ‫and so therefore, we now have access to the protected route. 78 00:04:02,070 --> 00:04:02,903 ‫Okay? 79 00:04:02,903 --> 00:04:06,203 ‫But what I wanted to see is this decoded object here. 80 00:04:07,230 --> 00:04:09,910 ‫And so this here should be the user ID. 81 00:04:09,910 --> 00:04:12,530 ‫So let's take a look at that in Postman again. 82 00:04:12,530 --> 00:04:13,423 ‫So 62a42. 83 00:04:15,520 --> 00:04:18,740 ‫And so, indeed, well, where do we have that? 84 00:04:18,740 --> 00:04:20,193 ‫Let's take a look at Compass. 85 00:04:21,240 --> 00:04:24,813 ‫And indeed, the ID of this user is this 62a42. 86 00:04:27,160 --> 00:04:29,347 ‫And so that means that we actually have 87 00:04:29,347 --> 00:04:31,340 ‫our correct payload here. 88 00:04:31,340 --> 00:04:33,420 ‫So basically, the correct user ID. 89 00:04:33,420 --> 00:04:36,460 ‫We then also have the timestamp of the creation date 90 00:04:36,460 --> 00:04:39,500 ‫and of the expiration date of the token, as well. 91 00:04:39,500 --> 00:04:40,700 ‫So this is working. 92 00:04:40,700 --> 00:04:43,710 ‫But now let's actually try to manipulate the payload 93 00:04:43,710 --> 00:04:44,563 ‫of this token. 94 00:04:47,088 --> 00:04:49,090 ‫So let's copy it here again. 95 00:04:49,090 --> 00:04:52,443 ‫But then I'm going to the JWT debugger. 96 00:04:54,640 --> 00:04:57,023 ‫So again, at jwt.io. 97 00:05:00,290 --> 00:05:02,363 ‫So let's take this away. 98 00:05:03,310 --> 00:05:06,010 ‫And now what I'm going to do is to change some data here 99 00:05:06,010 --> 00:05:09,260 ‫and that will then change the encoded token here, 100 00:05:09,260 --> 00:05:11,010 ‫which I can then go ahead and copy. 101 00:05:12,420 --> 00:05:14,693 ‫So let's simply replace, 102 00:05:15,580 --> 00:05:19,050 ‫actually, I will just replace these two numbers here 103 00:05:19,050 --> 00:05:20,940 ‫with something different. 104 00:05:20,940 --> 00:05:23,590 ‫And so, as you see, this changed the token over here. 105 00:05:23,590 --> 00:05:26,040 ‫And so now, I will actually try to get access 106 00:05:26,040 --> 00:05:27,470 ‫to that protected route 107 00:05:27,470 --> 00:05:30,373 ‫using this manipulated JSON web token. 108 00:05:31,460 --> 00:05:33,133 ‫Okay, make sense? 109 00:05:34,100 --> 00:05:37,023 ‫So just to see if it's working correctly. 110 00:05:38,632 --> 00:05:39,970 ‫So I'm copying this one here now 111 00:05:39,970 --> 00:05:42,660 ‫and pasting this other different one. 112 00:05:42,660 --> 00:05:47,310 ‫And so, if I now send this request, then we get an error. 113 00:05:47,310 --> 00:05:48,250 ‫So, great. 114 00:05:48,250 --> 00:05:50,843 ‫So, we see the error name is JsonWebTokenError, 115 00:05:51,840 --> 00:05:54,220 ‫and we have an invalid signature. 116 00:05:54,220 --> 00:05:55,160 ‫So, great. 117 00:05:55,160 --> 00:05:57,650 ‫That's exactly what we were looking for. 118 00:05:57,650 --> 00:06:00,210 ‫So that is one of the two errors that can occur. 119 00:06:00,210 --> 00:06:02,853 ‫The other one is that the token has already expired. 120 00:06:04,359 --> 00:06:07,180 ‫So this one is called JsonWebTokenError, 121 00:06:07,180 --> 00:06:10,890 ‫and so actually, let's go ahead and handle this error now. 122 00:06:10,890 --> 00:06:12,240 ‫And the way we could do it 123 00:06:12,240 --> 00:06:16,470 ‫is to add a try-catch block right here. 124 00:06:16,470 --> 00:06:17,460 ‫Right? 125 00:06:17,460 --> 00:06:19,600 ‫So right after doing this code, 126 00:06:19,600 --> 00:06:21,510 ‫we could introduce a try block, 127 00:06:21,510 --> 00:06:24,260 ‫and then in the catch, we would then create errors 128 00:06:24,260 --> 00:06:26,290 ‫that would be sent to the client. 129 00:06:26,290 --> 00:06:28,070 ‫Now, instead of doing it that way, 130 00:06:28,070 --> 00:06:30,970 ‫I actually want to use our global error-handling middleware 131 00:06:30,970 --> 00:06:33,290 ‫in order to do that for us. 132 00:06:33,290 --> 00:06:35,850 ‫So we don't like to do error handling right here 133 00:06:35,850 --> 00:06:37,220 ‫in our middleware function. 134 00:06:37,220 --> 00:06:41,140 ‫Instead, we usually delegate it to the error controller. 135 00:06:41,140 --> 00:06:43,940 ‫And so, let's do that exact same thing here. 136 00:06:43,940 --> 00:06:46,710 ‫So error controller. 137 00:06:46,710 --> 00:06:48,600 ‫And then it's actually the exact same thing 138 00:06:48,600 --> 00:06:50,930 ‫as we have with our other errors here. 139 00:06:50,930 --> 00:06:54,210 ‫So for example, the validation error coming from Mongoose, 140 00:06:54,210 --> 00:06:55,670 ‫so from another library. 141 00:06:55,670 --> 00:06:59,060 ‫And now, this error is actually coming from another library 142 00:06:59,060 --> 00:07:02,180 ‫and it also has its own name. 143 00:07:02,180 --> 00:07:03,470 ‫So let's get that. 144 00:07:03,470 --> 00:07:04,820 ‫And it's JsonWebTokenError. 145 00:07:06,900 --> 00:07:07,940 ‫All right. 146 00:07:07,940 --> 00:07:09,923 ‫And so, let's do very similar here. 147 00:07:11,850 --> 00:07:12,683 ‫So if 148 00:07:15,477 --> 00:07:19,310 ‫.name is this, 149 00:07:19,310 --> 00:07:23,463 ‫then error should be equal to handle error. 150 00:07:27,010 --> 00:07:27,843 ‫Okay. 151 00:07:27,843 --> 00:07:30,430 ‫So let's go ahead and create this function, actually, 152 00:07:30,430 --> 00:07:31,953 ‫somewhere up here. 153 00:07:35,782 --> 00:07:37,810 ‫And this one is actually extremely simple. 154 00:07:37,810 --> 00:07:39,760 ‫All it does is to take an error 155 00:07:39,760 --> 00:07:41,433 ‫and then return a new AppError. 156 00:07:44,480 --> 00:07:45,320 ‫Okay? 157 00:07:45,320 --> 00:07:48,950 ‫So in this ES6 arrow function, as I hope you know, 158 00:07:48,950 --> 00:07:50,790 ‫we can write these one-liners 159 00:07:50,790 --> 00:07:53,610 ‫where we don't even have to specify the curly braces 160 00:07:53,610 --> 00:07:55,610 ‫and neither the return keyword. 161 00:07:55,610 --> 00:07:58,670 ‫So this will automatically and implicitly return 162 00:07:58,670 --> 00:08:00,123 ‫whatever we put here. 163 00:08:01,010 --> 00:08:01,843 ‫Right? 164 00:08:01,843 --> 00:08:04,763 ‫And so, what we want to say here is simply, 165 00:08:05,980 --> 00:08:07,273 ‫invalid token, 166 00:08:09,580 --> 00:08:12,640 ‫please log in again. 167 00:08:12,640 --> 00:08:15,000 ‫And then, the error code, just like before, 168 00:08:15,000 --> 00:08:17,463 ‫is a 401 for Unauthorized. 169 00:08:19,497 --> 00:08:22,410 ‫Now, this only works, remember, in production. 170 00:08:22,410 --> 00:08:24,883 ‫And so, if we did this now again, 171 00:08:24,883 --> 00:08:27,730 ‫then we would get the exact same thing. 172 00:08:27,730 --> 00:08:29,890 ‫And so, let's actually go back here 173 00:08:29,890 --> 00:08:32,340 ‫and run this in production. 174 00:08:32,340 --> 00:08:37,340 ‫So npm run start:production. 175 00:08:39,470 --> 00:08:40,733 ‫Yeah, just like that. 176 00:08:41,650 --> 00:08:43,890 ‫So if we try this now again, 177 00:08:43,890 --> 00:08:45,630 ‫let's see if we get our error. 178 00:08:45,630 --> 00:08:47,840 ‫And indeed, we do. 179 00:08:47,840 --> 00:08:50,040 ‫So if, right now, a user in production 180 00:08:50,040 --> 00:08:52,930 ‫tries to access our app with an invalid token, 181 00:08:52,930 --> 00:08:55,890 ‫well, then they get just this error message. 182 00:08:55,890 --> 00:08:57,120 ‫All right? 183 00:08:57,120 --> 00:08:59,920 ‫So that's the first error that we can get. 184 00:08:59,920 --> 00:09:01,560 ‫But another one is that the user 185 00:09:01,560 --> 00:09:03,500 ‫tries to access the application 186 00:09:03,500 --> 00:09:06,147 ‫with an already expired token. 187 00:09:06,147 --> 00:09:08,733 ‫And so, let's now try to create that error. 188 00:09:09,683 --> 00:09:13,080 ‫And in order to do that, I will change the time it takes 189 00:09:13,080 --> 00:09:14,943 ‫for the token to expire. 190 00:09:17,811 --> 00:09:19,190 ‫So right now, we have 90 days. 191 00:09:19,190 --> 00:09:22,183 ‫Let's put it to, like, five seconds. 192 00:09:23,078 --> 00:09:23,911 ‫Okay. 193 00:09:23,911 --> 00:09:24,870 ‫Give it a save. 194 00:09:24,870 --> 00:09:26,823 ‫And now try to log in again. 195 00:09:28,090 --> 00:09:30,943 ‫So let's actually save this one here, as well. 196 00:09:32,920 --> 00:09:37,043 ‫So, in users, and then log in. 197 00:09:39,060 --> 00:09:43,100 ‫So we can log in, and it will then give us a new token, 198 00:09:43,100 --> 00:09:46,100 ‫but this token is only valid for five seconds. 199 00:09:46,100 --> 00:09:49,550 ‫And so, these five seconds should have passed at this point. 200 00:09:49,550 --> 00:09:51,690 ‫So I will now copy this token 201 00:09:51,690 --> 00:09:55,713 ‫and try to access our protected route using that token. 202 00:09:58,529 --> 00:09:59,362 ‫So paste it here. 203 00:09:59,362 --> 00:10:01,630 ‫And now, let's see what we get. 204 00:10:01,630 --> 00:10:04,280 ‫And actually, for some reason, it did work. 205 00:10:04,280 --> 00:10:08,593 ‫So let's take a look at our JWT debugger again. 206 00:10:11,620 --> 00:10:14,160 ‫And it says, created May 2nd, 207 00:10:14,160 --> 00:10:16,720 ‫but expires only on July 31. 208 00:10:16,720 --> 00:10:21,023 ‫So something went wrong in that token creation, I guess. 209 00:10:22,140 --> 00:10:23,810 ‫And so, let's change this here again. 210 00:10:23,810 --> 00:10:25,993 ‫And I'm just gonna put five here. 211 00:10:27,270 --> 00:10:30,340 ‫And so, that five should then stand for five milliseconds, 212 00:10:30,340 --> 00:10:32,630 ‫or I can even, like, put 5000, 213 00:10:32,630 --> 00:10:34,733 ‫which should then be five seconds. 214 00:10:37,680 --> 00:10:38,890 ‫Okay. 215 00:10:38,890 --> 00:10:42,363 ‫So let me save it now again in order to restart the server. 216 00:10:43,240 --> 00:10:44,570 ‫Try it again. 217 00:10:44,570 --> 00:10:46,113 ‫So logging in again here. 218 00:10:47,680 --> 00:10:48,600 ‫All right. 219 00:10:48,600 --> 00:10:52,930 ‫So now all we need to do is to basically wait five seconds, 220 00:10:52,930 --> 00:10:56,933 ‫and that time should already have passed at this point. 221 00:11:00,230 --> 00:11:01,500 ‫Paste it here again. 222 00:11:01,500 --> 00:11:03,560 ‫And let's go. 223 00:11:03,560 --> 00:11:05,860 ‫And indeed, we get an error. 224 00:11:05,860 --> 00:11:09,850 ‫Now remember how this is basically the standard error 225 00:11:09,850 --> 00:11:13,230 ‫that we get in case we do not correctly handle that error 226 00:11:13,230 --> 00:11:14,700 ‫in our error handling. 227 00:11:14,700 --> 00:11:15,750 ‫Right? 228 00:11:15,750 --> 00:11:18,840 ‫So let's just take a look at the error. 229 00:11:18,840 --> 00:11:21,350 ‫And actually, we have it here in the console. 230 00:11:21,350 --> 00:11:24,620 ‫So let's see where that comes from. 231 00:11:24,620 --> 00:11:26,673 ‫And yeah, it comes from this place. 232 00:11:27,760 --> 00:11:31,690 ‫So this is the case in where we have an unknown error. 233 00:11:31,690 --> 00:11:34,090 ‫Remember, so an error that is not marked 234 00:11:34,090 --> 00:11:35,640 ‫as an operational error, 235 00:11:35,640 --> 00:11:37,543 ‫and so therefore we want to log it. 236 00:11:38,500 --> 00:11:39,650 ‫So we log it here 237 00:11:39,650 --> 00:11:42,150 ‫and then we send this generic error message 238 00:11:42,150 --> 00:11:43,270 ‫down to the client, 239 00:11:43,270 --> 00:11:45,610 ‫so the one we just saw in Postman. 240 00:11:45,610 --> 00:11:48,100 ‫But here we actually the details from this error. 241 00:11:48,100 --> 00:11:51,480 ‫And so, this one has the name of TokenExpiredError. 242 00:11:51,480 --> 00:11:52,313 ‫All right. 243 00:11:52,313 --> 00:11:55,360 ‫And so, let's now handle this one as well. 244 00:11:55,360 --> 00:11:57,171 ‫So I'm copying it now, 245 00:11:57,171 --> 00:12:02,171 ‫and then create just another if here. 246 00:12:02,300 --> 00:12:07,300 ‫So if the error.name equals this one, 247 00:12:08,980 --> 00:12:10,343 ‫well then, let's say, 248 00:12:12,711 --> 00:12:14,461 ‫handleJWTExpiredError 249 00:12:18,640 --> 00:12:20,233 ‫with the arrow. 250 00:12:22,568 --> 00:12:25,750 ‫Let's copy it and put it right here. 251 00:12:33,186 --> 00:12:37,770 ‫And so this, of course, is very similar to the one before. 252 00:12:37,770 --> 00:12:40,493 ‫Your token has expired. 253 00:12:43,940 --> 00:12:45,193 ‫Please log in again. 254 00:12:48,670 --> 00:12:51,423 ‫And again, with a 401 error code. 255 00:12:52,360 --> 00:12:54,270 ‫Okay, let's try that again. 256 00:12:54,270 --> 00:12:56,043 ‫And so, that's exactly the error message 257 00:12:56,043 --> 00:12:58,023 ‫that we should now see here. 258 00:12:59,430 --> 00:13:00,263 ‫All right. 259 00:13:00,263 --> 00:13:01,263 ‫And indeed, it is. 260 00:13:02,480 --> 00:13:03,520 ‫Great. 261 00:13:03,520 --> 00:13:04,980 ‫Let's finish the process here 262 00:13:04,980 --> 00:13:07,560 ‫and start it in dev mode, of course. 263 00:13:07,560 --> 00:13:10,213 ‫So npm start, 264 00:13:11,700 --> 00:13:13,740 ‫and all right. 265 00:13:13,740 --> 00:13:17,460 ‫So this one, we don't need any more, so let's close it. 266 00:13:17,460 --> 00:13:19,880 ‫Or actually, let's fix this small error here, 267 00:13:19,880 --> 00:13:23,113 ‫because indeed, we do not use this error here at all. 268 00:13:24,170 --> 00:13:25,423 ‫So let's get rid of it. 269 00:13:29,260 --> 00:13:32,063 ‫And then down here, we don't need to pass it in there. 270 00:13:39,290 --> 00:13:40,123 ‫Cool. 271 00:13:41,060 --> 00:13:44,423 ‫We, of course, also need to change this back to 90 days. 272 00:13:47,200 --> 00:13:48,040 ‫All right. 273 00:13:48,040 --> 00:13:51,560 ‫And so, just to be really sure, 274 00:13:51,560 --> 00:13:52,803 ‫let's log in here again, 275 00:13:53,830 --> 00:13:55,513 ‫copy the token, 276 00:13:56,680 --> 00:13:59,050 ‫and put it here. 277 00:13:59,050 --> 00:14:01,750 ‫Now, this process here of copying the token 278 00:14:01,750 --> 00:14:04,190 ‫and then pasting it here in this header 279 00:14:04,190 --> 00:14:05,640 ‫may seem a bit weird, 280 00:14:05,640 --> 00:14:07,230 ‫and actually we're going to fix that 281 00:14:07,230 --> 00:14:09,030 ‫in one of the future videos 282 00:14:09,030 --> 00:14:12,070 ‫so that basically, this process happens automatically. 283 00:14:12,070 --> 00:14:13,970 ‫But now, what's important is that 284 00:14:13,970 --> 00:14:16,750 ‫it's actually back to working now. 285 00:14:16,750 --> 00:14:21,027 ‫So we can actually get rid of this console.log here 286 00:14:21,027 --> 00:14:24,250 ‫and move on to the next step. 287 00:14:24,250 --> 00:14:27,010 ‫And we could actually stop here now if we wanted. 288 00:14:27,010 --> 00:14:30,130 ‫And again, most tutorials that you're gonna find out there 289 00:14:30,130 --> 00:14:32,420 ‫would, in fact, just stop here. 290 00:14:32,420 --> 00:14:35,210 ‫But this is not really secure enough just yet. 291 00:14:35,210 --> 00:14:37,550 ‫So for example, what if the user 292 00:14:37,550 --> 00:14:39,840 ‫has been deleted in the meantime? 293 00:14:39,840 --> 00:14:41,800 ‫So the token will still exist, 294 00:14:41,800 --> 00:14:43,900 ‫but if the user is no longer existent, 295 00:14:43,900 --> 00:14:47,780 ‫well then we actually don't want to log him in, right? 296 00:14:47,780 --> 00:14:50,070 ‫Or even worse, what if the user 297 00:14:50,070 --> 00:14:52,130 ‫has actually changed his password 298 00:14:52,130 --> 00:14:54,360 ‫after the token has been issued? 299 00:14:54,360 --> 00:14:56,950 ‫Well, that should also not work, right? 300 00:14:56,950 --> 00:15:00,750 ‫For example, imagine that someone stole the JSON web token 301 00:15:00,750 --> 00:15:01,870 ‫from a user. 302 00:15:01,870 --> 00:15:04,380 ‫But then, in order to protect against that, 303 00:15:04,380 --> 00:15:06,770 ‫the user changes his password. 304 00:15:06,770 --> 00:15:09,270 ‫And so, of course, that old token that was issued 305 00:15:09,270 --> 00:15:12,940 ‫before the password change should no longer be valid. 306 00:15:12,940 --> 00:15:16,906 ‫So it should not be accepted to access protected routes. 307 00:15:16,906 --> 00:15:19,550 ‫And so, that's the kind of stuff that we're gonna implement 308 00:15:19,550 --> 00:15:22,060 ‫here in step three and step four. 309 00:15:22,060 --> 00:15:23,120 ‫So the first thing to do 310 00:15:23,120 --> 00:15:26,060 ‫is to check if the user actually still exists. 311 00:15:26,060 --> 00:15:28,690 ‫And so, that one should be the easiest one. 312 00:15:28,690 --> 00:15:32,463 ‫So let's just say, User.findById. 313 00:15:36,568 --> 00:15:38,440 ‫And so, this is now why we actually have 314 00:15:38,440 --> 00:15:40,540 ‫the ID in the payload, 315 00:15:40,540 --> 00:15:42,767 ‫because we can now use that ID 316 00:15:42,767 --> 00:15:46,530 ‫and query the user using just that ID. 317 00:15:46,530 --> 00:15:49,390 ‫So decoded.id. 318 00:15:49,390 --> 00:15:50,223 ‫All right? 319 00:15:50,223 --> 00:15:53,110 ‫So that should then find the new user. 320 00:15:53,110 --> 00:15:55,860 ‫And of course, we need to await that 321 00:15:55,860 --> 00:15:59,560 ‫and then store it into a variable. 322 00:15:59,560 --> 00:16:01,480 ‫I'm calling it the freshUser. 323 00:16:03,148 --> 00:16:03,981 ‫All right? 324 00:16:03,981 --> 00:16:05,460 ‫Because it's not really a new user. 325 00:16:05,460 --> 00:16:07,300 ‫That's only when we create one. 326 00:16:07,300 --> 00:16:09,030 ‫But this is not really a new one, 327 00:16:09,030 --> 00:16:12,980 ‫it's really just the user based on the decoded ID. 328 00:16:12,980 --> 00:16:13,870 ‫Okay? 329 00:16:13,870 --> 00:16:16,833 ‫And we can do this so we can be 100% sure 330 00:16:16,833 --> 00:16:18,990 ‫that the ID is actually correct, 331 00:16:18,990 --> 00:16:22,460 ‫because if we made it until this point of the code here 332 00:16:22,460 --> 00:16:25,110 ‫then that means that the verification process 333 00:16:25,110 --> 00:16:28,200 ‫that we have previously, here, was successful. 334 00:16:28,200 --> 00:16:30,220 ‫Otherwise, this would have caused an error 335 00:16:30,220 --> 00:16:31,490 ‫which would then have prevented 336 00:16:31,490 --> 00:16:33,410 ‫the function from continuing. 337 00:16:33,410 --> 00:16:36,660 ‫And so, again, this verification process here 338 00:16:36,660 --> 00:16:38,620 ‫is in charge of verification 339 00:16:38,620 --> 00:16:40,900 ‫if no one altered the ID 340 00:16:40,900 --> 00:16:43,033 ‫that's in the payload of this token. 341 00:16:43,970 --> 00:16:46,970 ‫And so, because of that, we can be 100% sure 342 00:16:46,970 --> 00:16:50,600 ‫that the user for which we have issued the JWT 343 00:16:50,600 --> 00:16:52,790 ‫is exactly the one whose ID 344 00:16:52,790 --> 00:16:56,810 ‫is now inside of the decoded payload, so this one. 345 00:16:56,810 --> 00:16:57,690 ‫Okay? 346 00:16:57,690 --> 00:17:00,440 ‫So the verification process is really key. 347 00:17:00,440 --> 00:17:02,440 ‫It's really what makes all of this work. 348 00:17:04,730 --> 00:17:06,410 ‫Anyway, now what we need to do 349 00:17:06,410 --> 00:17:09,570 ‫is to check if there actually is a freshUser. 350 00:17:09,570 --> 00:17:11,570 ‫And if not, well then, of course, 351 00:17:11,570 --> 00:17:13,844 ‫we're going to return a new error. 352 00:17:13,844 --> 00:17:16,577 ‫So if there is no freshUser, 353 00:17:19,880 --> 00:17:22,100 ‫then return from this middleware 354 00:17:22,100 --> 00:17:24,083 ‫and call the next one with an error. 355 00:17:24,920 --> 00:17:27,100 ‫So this is a pattern that we've been seeing 356 00:17:27,100 --> 00:17:29,403 ‫over and over again at this point, right? 357 00:17:30,350 --> 00:17:31,490 ‫So the token 358 00:17:35,470 --> 00:17:39,173 ‫does no longer exist. 359 00:17:40,810 --> 00:17:42,750 ‫And actually, it's the other way around. 360 00:17:42,750 --> 00:17:45,200 ‫So actually, the user belonging to the token 361 00:17:47,170 --> 00:17:48,680 ‫no longer exists. 362 00:17:48,680 --> 00:17:49,513 ‫Right? 363 00:17:49,513 --> 00:17:51,297 ‫And then, the 401. 364 00:17:53,780 --> 00:17:54,920 ‫Okay. 365 00:17:54,920 --> 00:17:57,860 ‫So let's test this once again. 366 00:17:57,860 --> 00:18:00,843 ‫And let's actually create a new user for that. 367 00:18:02,620 --> 00:18:04,880 ‫So just test with the same password 368 00:18:04,880 --> 00:18:06,590 ‫so we're always using the same one here 369 00:18:06,590 --> 00:18:09,160 ‫just to make our testing a bit easier. 370 00:18:09,160 --> 00:18:11,070 ‫And I know that all of this testing here 371 00:18:11,070 --> 00:18:14,440 ‫makes the video take really quite a long time, 372 00:18:14,440 --> 00:18:15,900 ‫but of course, it's really important 373 00:18:15,900 --> 00:18:17,950 ‫that we do test everything that we do, 374 00:18:17,950 --> 00:18:21,713 ‫especially in such an important topic as authentication. 375 00:18:23,071 --> 00:18:27,780 ‫So I'm now using this JWT here, so I'm pasting it here, 376 00:18:27,780 --> 00:18:30,630 ‫but of course, before sending the request, 377 00:18:30,630 --> 00:18:33,573 ‫I will go ahead and delete that user right away. 378 00:18:34,650 --> 00:18:35,690 ‫Okay? 379 00:18:35,690 --> 00:18:37,690 ‫So again, let's pretend someone 380 00:18:37,690 --> 00:18:40,020 ‫created a user then logged in, 381 00:18:40,020 --> 00:18:43,500 ‫and let's say, then, after some time, the user was deleted. 382 00:18:43,500 --> 00:18:44,333 ‫But in the meantime, 383 00:18:44,333 --> 00:18:47,410 ‫someone could've gotten access to that JWT, 384 00:18:47,410 --> 00:18:50,030 ‫and could now try to log in as that user 385 00:18:50,030 --> 00:18:52,580 ‫that was, in fact, already deleted. 386 00:18:52,580 --> 00:18:55,520 ‫And so, again, we should not let that happen. 387 00:18:55,520 --> 00:18:57,713 ‫So let me delete this user here now. 388 00:18:59,010 --> 00:18:59,943 ‫And there we go. 389 00:19:01,720 --> 00:19:03,630 ‫And so, let's test it now. 390 00:19:03,630 --> 00:19:07,060 ‫And again, keep in mind that the user belonging to the ID 391 00:19:07,060 --> 00:19:10,690 ‫which is in this payload is now no longer there. 392 00:19:10,690 --> 00:19:12,040 ‫So let's see. 393 00:19:12,040 --> 00:19:16,313 ‫And indeed, we get this error message that we just created. 394 00:19:17,520 --> 00:19:20,200 ‫So that one is working as well. 395 00:19:20,200 --> 00:19:22,400 ‫And let's go to the last one. 396 00:19:22,400 --> 00:19:23,830 ‫So step number four, 397 00:19:23,830 --> 00:19:27,070 ‫check if user has recently changed their password. 398 00:19:27,070 --> 00:19:30,100 ‫So basically, after the token was issued. 399 00:19:30,100 --> 00:19:31,550 ‫And to implement this test, 400 00:19:31,550 --> 00:19:34,260 ‫we will actually create another instance method. 401 00:19:34,260 --> 00:19:37,030 ‫So basically, a method that is going to be available 402 00:19:37,030 --> 00:19:38,330 ‫on all the documents. 403 00:19:38,330 --> 00:19:41,410 ‫So documents are instances of a model. 404 00:19:41,410 --> 00:19:42,243 ‫All right? 405 00:19:42,243 --> 00:19:44,490 ‫And we do this because it's quite a lot of code 406 00:19:44,490 --> 00:19:46,540 ‫that we need for this verification. 407 00:19:46,540 --> 00:19:50,040 ‫And so, actually, this code belongs to the User model 408 00:19:50,040 --> 00:19:51,970 ‫and not really to the controller. 409 00:19:51,970 --> 00:19:52,803 ‫Okay? 410 00:19:52,803 --> 00:19:55,050 ‫And so, let's do that just like we did before 411 00:19:55,050 --> 00:19:57,270 ‫for checking the password. 412 00:19:57,270 --> 00:19:59,840 ‫So in User model, we already implemented 413 00:19:59,840 --> 00:20:04,710 ‫this correctPassword static instance method, remember? 414 00:20:04,710 --> 00:20:06,903 ‫And so, let's now create another one. 415 00:20:08,339 --> 00:20:13,339 ‫So userSchema.methods.changedPasswordAfter. 416 00:20:22,390 --> 00:20:24,550 ‫So function, and into this function, 417 00:20:24,550 --> 00:20:27,530 ‫we will pass the JWT timestamp. 418 00:20:27,530 --> 00:20:29,630 ‫So basically, that timestamp which says 419 00:20:29,630 --> 00:20:32,190 ‫when the token was issued. 420 00:20:32,190 --> 00:20:34,437 ‫So let's call that JWTTimestamp. 421 00:20:40,310 --> 00:20:41,143 ‫All right. 422 00:20:41,143 --> 00:20:44,600 ‫And by default, we will return false from this method. 423 00:20:44,600 --> 00:20:45,720 ‫And that will then mean 424 00:20:45,720 --> 00:20:48,320 ‫that the user has not changed his password 425 00:20:48,320 --> 00:20:50,410 ‫after the token was issued. 426 00:20:50,410 --> 00:20:51,860 ‫Okay? 427 00:20:51,860 --> 00:20:56,860 ‫So let's put that here, return false, basically by default. 428 00:20:58,470 --> 00:20:59,303 ‫Okay. 429 00:20:59,303 --> 00:21:02,987 ‫But then, we also have if this, 430 00:21:02,987 --> 00:21:05,827 ‫and remember that in an instance method, 431 00:21:05,827 --> 00:21:09,477 ‫the this keyword always points to the current document. 432 00:21:09,477 --> 00:21:13,210 ‫And so therefore, here we have access to the properties. 433 00:21:13,210 --> 00:21:16,280 ‫Now, we actually need to create a field now in our schema 434 00:21:16,280 --> 00:21:18,750 ‫for the date where the password has been changed. 435 00:21:18,750 --> 00:21:20,050 ‫So we don't have that yet. 436 00:21:21,200 --> 00:21:23,713 ‫So let's quickly add it here. 437 00:21:25,980 --> 00:21:27,813 ‫So passwordChangedAt, 438 00:21:31,320 --> 00:21:34,520 ‫and the type of it will be a Date. 439 00:21:34,520 --> 00:21:37,890 ‫Now, this passwordChangedAt property here 440 00:21:37,890 --> 00:21:40,160 ‫will always be changed, of course, 441 00:21:40,160 --> 00:21:42,910 ‫when someone change the password. 442 00:21:42,910 --> 00:21:45,270 ‫So right now, we don't have that logic anywhere, 443 00:21:45,270 --> 00:21:48,743 ‫and so nowhere we are actually defining this property. 444 00:21:49,630 --> 00:21:53,230 ‫And so, most of the documents, so most of the users, 445 00:21:53,230 --> 00:21:56,720 ‫they will simply not have this property in their data, 446 00:21:56,720 --> 00:21:58,600 ‫so in their object, right? 447 00:21:58,600 --> 00:22:01,363 ‫And so, of course, we need to test for that. 448 00:22:03,430 --> 00:22:04,610 ‫Okay? 449 00:22:04,610 --> 00:22:07,740 ‫So if the passwordChangedAt property exists, 450 00:22:07,740 --> 00:22:11,510 ‫only then we want to actually do the comparison. 451 00:22:11,510 --> 00:22:12,343 ‫Okay? 452 00:22:12,343 --> 00:22:16,010 ‫But if not, so if passwordChanged does not exist, 453 00:22:16,010 --> 00:22:17,640 ‫well then that means that the user 454 00:22:17,640 --> 00:22:20,020 ‫has never actually changed the password, 455 00:22:20,020 --> 00:22:23,171 ‫and so therefore we can simply return false. 456 00:22:23,171 --> 00:22:25,560 ‫So again, that's our default, 457 00:22:25,560 --> 00:22:28,190 ‫meaning that the user has not changed the password 458 00:22:28,190 --> 00:22:30,540 ‫after this timestamp. 459 00:22:30,540 --> 00:22:31,373 ‫Okay. 460 00:22:31,373 --> 00:22:35,760 ‫And now, just to start, let's actually log to the console 461 00:22:35,760 --> 00:22:37,933 ‫this.passwordChangedAt, 462 00:22:39,370 --> 00:22:42,010 ‫and of course, the JWTTimestamp as well, 463 00:22:42,010 --> 00:22:44,950 ‫just so we can see how we could compare them. 464 00:22:44,950 --> 00:22:45,783 ‫All right. 465 00:22:47,560 --> 00:22:49,690 ‫And now we need to actually create a user 466 00:22:49,690 --> 00:22:52,720 ‫which has this property on it, okay? 467 00:22:52,720 --> 00:22:54,260 ‫And again, later in the section 468 00:22:54,260 --> 00:22:57,280 ‫when we will implement the logic for changing the password 469 00:22:57,280 --> 00:22:59,760 ‫is when we will then set this property. 470 00:22:59,760 --> 00:23:00,593 ‫Okay? 471 00:23:00,593 --> 00:23:04,140 ‫But now we will artificially, basically, set it here 472 00:23:04,140 --> 00:23:06,260 ‫when we create a new user. 473 00:23:06,260 --> 00:23:07,093 ‫Okay? 474 00:23:08,690 --> 00:23:10,130 ‫So let's put that here. 475 00:23:10,130 --> 00:23:12,810 ‫And here, any date, actually, will serve. 476 00:23:12,810 --> 00:23:17,810 ‫So let's say 30 April 2019 here. 477 00:23:18,430 --> 00:23:21,313 ‫And so that should then be parsed into MongoDB just fine. 478 00:23:22,460 --> 00:23:24,293 ‫Let's try that, see if it works. 479 00:23:25,210 --> 00:23:26,520 ‫And that didn't work. 480 00:23:26,520 --> 00:23:29,913 ‫So it couldn't really parse the date, let's say. 481 00:23:30,980 --> 00:23:33,710 ‫And actually, I need to start with the year 482 00:23:33,710 --> 00:23:36,400 ‫and then the day at the end. 483 00:23:36,400 --> 00:23:41,050 ‫So 2019 and then 30 of April. 484 00:23:41,050 --> 00:23:42,103 ‫Try that again. 485 00:23:43,190 --> 00:23:45,300 ‫And so you see that now it's actually working. 486 00:23:45,300 --> 00:23:48,210 ‫So we have this parsed date here. 487 00:23:48,210 --> 00:23:49,350 ‫Okay? 488 00:23:49,350 --> 00:23:51,910 ‫Now, in order to actually see the result of this, 489 00:23:51,910 --> 00:23:55,040 ‫we, of course, need to call this method. 490 00:23:55,040 --> 00:23:56,560 ‫Okay? 491 00:23:56,560 --> 00:23:59,033 ‫So that's what we're gonna do here in step four. 492 00:24:00,010 --> 00:24:01,110 ‫Okay? 493 00:24:01,110 --> 00:24:04,630 ‫And so, remember that we can call this instance method 494 00:24:04,630 --> 00:24:06,200 ‫on a user document. 495 00:24:06,200 --> 00:24:09,197 ‫So freshUser.changedPasswordAfter, 496 00:24:14,837 --> 00:24:17,370 ‫and then that timestamp. 497 00:24:17,370 --> 00:24:22,370 ‫So that's at decoded.iat, so issued at, basically. 498 00:24:25,450 --> 00:24:26,350 ‫All right. 499 00:24:26,350 --> 00:24:29,130 ‫So let's simply see the result of doing that. 500 00:24:29,130 --> 00:24:32,953 ‫And so, of course, this should now, not here, 501 00:24:33,870 --> 00:24:37,123 ‫so this should now log to the console these two values. 502 00:24:39,320 --> 00:24:40,153 ‫Okay. 503 00:24:40,153 --> 00:24:43,170 ‫Now, of course I need to log in with exactly this user, 504 00:24:43,170 --> 00:24:44,223 ‫so with test, 505 00:24:47,780 --> 00:24:48,853 ‫so here we go. 506 00:24:50,250 --> 00:24:51,173 ‫Log in. 507 00:24:53,090 --> 00:24:56,200 ‫Copy this token here again. 508 00:24:56,200 --> 00:24:59,580 ‫And again, we're gonna basically automate that 509 00:24:59,580 --> 00:25:01,233 ‫in the next video, actually. 510 00:25:02,740 --> 00:25:03,700 ‫Okay. 511 00:25:03,700 --> 00:25:04,673 ‫Paste it here. 512 00:25:05,670 --> 00:25:08,312 ‫And now, we actually get this bug here. 513 00:25:08,312 --> 00:25:13,312 ‫So I just misspelled this function name here. 514 00:25:13,670 --> 00:25:14,920 ‫Well, let's just copy it. 515 00:25:16,410 --> 00:25:17,403 ‫Try it again. 516 00:25:18,780 --> 00:25:20,150 ‫Oh man. 517 00:25:20,150 --> 00:25:21,823 ‫What's going wrong now? 518 00:25:25,420 --> 00:25:27,633 ‫And I see I simply forgot this log here. 519 00:25:28,752 --> 00:25:30,090 ‫So another stupid mistake. 520 00:25:30,090 --> 00:25:32,320 ‫Probably saw that one coming. 521 00:25:32,320 --> 00:25:33,550 ‫But now here we go. 522 00:25:33,550 --> 00:25:35,120 ‫So everything worked fine, 523 00:25:35,120 --> 00:25:37,450 ‫and all we really wanted to see for now 524 00:25:37,450 --> 00:25:39,560 ‫is these two results. 525 00:25:39,560 --> 00:25:43,110 ‫So we basically have this one here this date format, 526 00:25:43,110 --> 00:25:43,943 ‫and then the other one 527 00:25:43,943 --> 00:25:47,600 ‫in this millisecond or second timestamp here. 528 00:25:47,600 --> 00:25:51,670 ‫And so, we now need to convert this passwordChangedAt 529 00:25:51,670 --> 00:25:54,240 ‫also to a timestamp like that. 530 00:25:54,240 --> 00:25:55,073 ‫All right? 531 00:25:55,073 --> 00:25:57,853 ‫And so, for that, let's create a new variable. 532 00:25:59,560 --> 00:26:01,330 ‫So changedTimestamp. 533 00:26:03,800 --> 00:26:06,100 ‫And we can use this.passwordChangedAt.getTime. 534 00:26:12,730 --> 00:26:13,563 ‫Okay? 535 00:26:13,563 --> 00:26:16,913 ‫And so, that's one of the many, many date functions 536 00:26:16,913 --> 00:26:18,563 ‫that JavaScript gives us. 537 00:26:19,450 --> 00:26:20,960 ‫All right. 538 00:26:20,960 --> 00:26:23,760 ‫And now, let's quickly compare these two 539 00:26:23,760 --> 00:26:26,253 ‫because we're not quite ready yet, actually. 540 00:26:28,770 --> 00:26:31,930 ‫So sending it just to see the results here. 541 00:26:31,930 --> 00:26:33,610 ‫And so what we see here basically 542 00:26:33,610 --> 00:26:36,580 ‫is that this one here is now, basically, in seconds, 543 00:26:36,580 --> 00:26:38,210 ‫and this one in milliseconds. 544 00:26:38,210 --> 00:26:40,540 ‫So it's 1000 times more. 545 00:26:40,540 --> 00:26:43,340 ‫And so, we know we need to divide this by 1000 546 00:26:45,630 --> 00:26:48,583 ‫and then parse this entire thing as an integer. 547 00:26:50,550 --> 00:26:52,820 ‫And for that, we use parseInt. 548 00:26:52,820 --> 00:26:57,180 ‫So another JavaScript function that's available for numbers. 549 00:26:57,180 --> 00:27:00,320 ‫And then we actually also need to specify the base. 550 00:27:00,320 --> 00:27:02,920 ‫So this is a base 10 number. 551 00:27:02,920 --> 00:27:03,970 ‫All right? 552 00:27:03,970 --> 00:27:07,373 ‫And so now, let's actually, again, see the result. 553 00:27:10,120 --> 00:27:13,360 ‫And now, that looks a lot friendlier. 554 00:27:13,360 --> 00:27:14,193 ‫Okay. 555 00:27:14,193 --> 00:27:17,040 ‫And so, now let's actually return our result. 556 00:27:17,040 --> 00:27:22,040 ‫And again, keep in mind that false means not changed. 557 00:27:24,500 --> 00:27:25,520 ‫Okay? 558 00:27:25,520 --> 00:27:30,207 ‫And not changed basically means that the day or the time 559 00:27:32,300 --> 00:27:34,240 ‫at which the token was issued 560 00:27:34,240 --> 00:27:37,893 ‫is less than the changed timestamp. 561 00:27:40,280 --> 00:27:41,113 ‫Okay? 562 00:27:44,330 --> 00:27:45,830 ‫So just as an example here, 563 00:27:45,830 --> 00:27:49,327 ‫let's say that the token was issued at time 100. 564 00:27:50,460 --> 00:27:53,843 ‫But then, we changed the password, let's say, at time 200. 565 00:27:55,240 --> 00:27:56,073 ‫Okay? 566 00:27:56,073 --> 00:27:57,609 ‫And so, we changed 567 00:27:57,609 --> 00:27:59,840 ‫the password after the token was issued, 568 00:27:59,840 --> 00:28:01,940 ‫and so therefore, this is now true. 569 00:28:01,940 --> 00:28:03,379 ‫All right? 570 00:28:03,379 --> 00:28:04,810 ‫And that's exactly what we want to return here, 571 00:28:04,810 --> 00:28:06,910 ‫because false means not changed, 572 00:28:06,910 --> 00:28:09,200 ‫and so true, of course, means changed. 573 00:28:09,200 --> 00:28:11,980 ‫And so, that's exactly what we have here. 574 00:28:11,980 --> 00:28:13,410 ‫But now, let's say that the password 575 00:28:13,410 --> 00:28:15,810 ‫was last changed at 200, 576 00:28:15,810 --> 00:28:18,640 ‫but then only after that, we issued the token, 577 00:28:18,640 --> 00:28:21,260 ‫so let's say, at time 300. 578 00:28:21,260 --> 00:28:23,660 ‫And so, 300, less than 200? 579 00:28:23,660 --> 00:28:25,160 ‫No, that's false. 580 00:28:25,160 --> 00:28:29,200 ‫And so, we return false, which again means not changed. 581 00:28:29,200 --> 00:28:32,720 ‫And so, that's why we use this less sign here. 582 00:28:32,720 --> 00:28:33,553 ‫Okay? 583 00:28:36,800 --> 00:28:41,800 ‫Let's go back to our controller and actually use this. 584 00:28:45,480 --> 00:28:49,910 ‫So if the password was actually changed, 585 00:28:49,910 --> 00:28:53,030 ‫well, in this case, we actually want an error. 586 00:28:53,030 --> 00:28:57,623 ‫So return next, again, a new AppError. 587 00:29:02,970 --> 00:29:04,220 ‫Recently... 588 00:29:11,790 --> 00:29:13,620 ‫Please log in again. 589 00:29:13,620 --> 00:29:15,030 ‫Okay. 590 00:29:15,030 --> 00:29:18,363 ‫And once more, code 401. 591 00:29:19,770 --> 00:29:20,820 ‫All right. 592 00:29:20,820 --> 00:29:23,220 ‫So again, this will return true 593 00:29:23,220 --> 00:29:25,790 ‫if the user actually changed their password. 594 00:29:25,790 --> 00:29:28,540 ‫And so, if all of this here is true, 595 00:29:28,540 --> 00:29:30,600 ‫well, then exactly in that case 596 00:29:30,600 --> 00:29:33,220 ‫is when we want this error to happen. 597 00:29:33,220 --> 00:29:34,820 ‫All right? 598 00:29:34,820 --> 00:29:37,510 ‫So that was actually the last step. 599 00:29:37,510 --> 00:29:38,952 ‫Okay. 600 00:29:38,952 --> 00:29:41,030 ‫So basically, if the code can make it all to the end 601 00:29:41,030 --> 00:29:45,410 ‫of this code here, only then, next will be executed. 602 00:29:45,410 --> 00:29:49,100 ‫And then, with next, we go to the next route handler, 603 00:29:49,100 --> 00:29:51,470 ‫which effectively means to grant access 604 00:29:51,470 --> 00:29:52,783 ‫to that protected route. 605 00:29:53,750 --> 00:29:55,740 ‫Let's actually put that here. 606 00:29:55,740 --> 00:30:00,740 ‫Grant access to protected route. 607 00:30:02,340 --> 00:30:03,597 ‫Okay? 608 00:30:03,597 --> 00:30:05,310 ‫Because that's really all this next does. 609 00:30:05,310 --> 00:30:08,070 ‫Next leads us to the next middleware, 610 00:30:08,070 --> 00:30:10,880 ‫which is usually, then, the route handler itself, 611 00:30:10,880 --> 00:30:14,550 ‫so the one which sends back the data that was protected. 612 00:30:14,550 --> 00:30:15,383 ‫Okay. 613 00:30:15,383 --> 00:30:18,540 ‫Just one last thing that we want to do here 614 00:30:18,540 --> 00:30:22,930 ‫is to actually then put the entire user data on the request. 615 00:30:22,930 --> 00:30:27,100 ‫So we can simply say, req, so request, .user 616 00:30:27,100 --> 00:30:30,510 ‫will be equal to the freshUser. 617 00:30:30,510 --> 00:30:31,343 ‫Okay. 618 00:30:31,343 --> 00:30:32,430 ‫And again, of course, 619 00:30:32,430 --> 00:30:34,930 ‫the code only ever reaches this point here 620 00:30:34,930 --> 00:30:37,470 ‫in case everything is correct. 621 00:30:37,470 --> 00:30:38,303 ‫Okay? 622 00:30:38,303 --> 00:30:40,710 ‫And so, this here might then be useful 623 00:30:40,710 --> 00:30:42,110 ‫at some point in the future. 624 00:30:43,150 --> 00:30:43,983 ‫Great. 625 00:30:43,983 --> 00:30:46,450 ‫Let's just test this one more time. 626 00:30:46,450 --> 00:30:51,450 ‫And basically, this change is in the past now. 627 00:30:51,820 --> 00:30:53,840 ‫And so, this token that we have here, 628 00:30:53,840 --> 00:30:56,890 ‫or actually, I could have reused just this one 629 00:30:56,890 --> 00:30:58,520 ‫instead of logging it again. 630 00:30:58,520 --> 00:31:00,500 ‫But anyway, this token was issued 631 00:31:00,500 --> 00:31:02,344 ‫after the password changed. 632 00:31:02,344 --> 00:31:04,920 ‫And so, this token should now work. 633 00:31:04,920 --> 00:31:07,500 ‫So let's actually log in again 634 00:31:10,900 --> 00:31:13,203 ‫and try it with this token. 635 00:31:18,020 --> 00:31:20,030 ‫And indeed, we get access. 636 00:31:20,030 --> 00:31:22,853 ‫Now, moving to Compass in order to change that date. 637 00:31:24,511 --> 00:31:26,010 ‫Okay. 638 00:31:26,010 --> 00:31:27,657 ‫Let's put it one month later. 639 00:31:27,657 --> 00:31:30,780 ‫And so, that will actually be in the future, 640 00:31:30,780 --> 00:31:34,150 ‫so at least, in my future when I'm recording this video. 641 00:31:34,150 --> 00:31:36,640 ‫Of course, you will be doing this at a later point. 642 00:31:36,640 --> 00:31:40,373 ‫And so, to test this, please put this in your future. 643 00:31:41,420 --> 00:31:43,060 ‫So in the future of the date 644 00:31:43,060 --> 00:31:44,710 ‫where you're watching this video. 645 00:31:45,960 --> 00:31:50,960 ‫So if I go now back to Postman and log in again, 646 00:31:53,860 --> 00:31:56,430 ‫okay, so if I log in again now 647 00:31:56,430 --> 00:31:58,710 ‫and try to access that route, 648 00:31:58,710 --> 00:32:01,420 ‫well, then this token will be issued, basically, 649 00:32:01,420 --> 00:32:03,553 ‫after the password has been changed. 650 00:32:08,680 --> 00:32:10,590 ‫Or actually before the password has been changed. 651 00:32:10,590 --> 00:32:12,610 ‫So, sorry for that confusion. 652 00:32:12,610 --> 00:32:15,800 ‫So the password was changed at May 30, 653 00:32:15,800 --> 00:32:19,650 ‫but this token was issued at May the 2nd, and so, before. 654 00:32:19,650 --> 00:32:21,950 ‫So basically, it's now as if the user 655 00:32:21,950 --> 00:32:25,880 ‫had changed their password after the token was issued. 656 00:32:25,880 --> 00:32:27,341 ‫And so, that's exactly the situation 657 00:32:27,341 --> 00:32:31,070 ‫where we don't want to give access to the protected route. 658 00:32:31,070 --> 00:32:35,170 ‫And so, this should now then reflect that. 659 00:32:35,170 --> 00:32:38,740 ‫And indeed, user recently changed password, 660 00:32:38,740 --> 00:32:40,280 ‫please log in again. 661 00:32:40,280 --> 00:32:41,240 ‫Great. 662 00:32:41,240 --> 00:32:42,953 ‫So that now works. 663 00:32:43,870 --> 00:32:48,000 ‫So our protect middleware is now completely implemented. 664 00:32:48,000 --> 00:32:51,620 ‫Let's just get rid of this console.log here. 665 00:32:51,620 --> 00:32:53,820 ‫Don't need that one any more. 666 00:32:53,820 --> 00:32:55,800 ‫And okay. 667 00:32:55,800 --> 00:32:57,230 ‫So let's quickly recap, 668 00:32:57,230 --> 00:32:59,520 ‫and this video is running very long, 669 00:32:59,520 --> 00:33:01,330 ‫bit longer than I expected. 670 00:33:01,330 --> 00:33:03,820 ‫But it's really important to understand 671 00:33:03,820 --> 00:33:06,700 ‫and to explain how all of this works 672 00:33:06,700 --> 00:33:07,810 ‫and why it's important. 673 00:33:07,810 --> 00:33:12,710 ‫And so, I prefer that than doing this video's much shorter. 674 00:33:12,710 --> 00:33:14,127 ‫Of course, I could just write the code, 675 00:33:14,127 --> 00:33:17,330 ‫but then you wouldn't really understand what's going on. 676 00:33:17,330 --> 00:33:19,410 ‫So this part we already understood. 677 00:33:19,410 --> 00:33:21,680 ‫Then this part, I believe as well, 678 00:33:21,680 --> 00:33:24,060 ‫so this is where the verification happens, 679 00:33:24,060 --> 00:33:26,570 ‫so basically seeing if the token payload 680 00:33:26,570 --> 00:33:30,900 ‫has not been manipulated by some malicious third party. 681 00:33:30,900 --> 00:33:31,733 ‫Okay? 682 00:33:31,733 --> 00:33:33,730 ‫And since we then reach this code here, 683 00:33:33,730 --> 00:33:36,790 ‫it means that no one changed the JSON web token, 684 00:33:36,790 --> 00:33:39,350 ‫and so therefore, we can get a fresh user. 685 00:33:39,350 --> 00:33:41,690 ‫So basically, we can get the current user, 686 00:33:41,690 --> 00:33:43,650 ‫let's actually call it currentUser. 687 00:33:43,650 --> 00:33:44,483 ‫Why not? 688 00:33:45,450 --> 00:33:47,993 ‫So here, here, and also here. 689 00:33:49,670 --> 00:33:50,503 ‫Okay? 690 00:33:50,503 --> 00:33:53,020 ‫So we can get the currentUser from that ID 691 00:33:53,020 --> 00:33:55,023 ‫that was just decoded from the payload. 692 00:33:56,100 --> 00:33:58,260 ‫Now, if the currentUser does not exist, 693 00:33:58,260 --> 00:34:00,660 ‫so this is what we're testing for here, 694 00:34:00,660 --> 00:34:01,990 ‫well, then in that case 695 00:34:01,990 --> 00:34:04,290 ‫we do not want to give access to the route, 696 00:34:04,290 --> 00:34:06,343 ‫and instead create this new error. 697 00:34:07,400 --> 00:34:08,870 ‫But if the user does exist, 698 00:34:08,870 --> 00:34:12,030 ‫well, then we make it to point number four, 699 00:34:12,030 --> 00:34:15,060 ‫where we then check if a password change has happened 700 00:34:15,060 --> 00:34:18,060 ‫after the token was issued, right? 701 00:34:18,060 --> 00:34:21,200 ‫And if it did, then again, we create a new error. 702 00:34:21,200 --> 00:34:22,720 ‫And if it did not, well, 703 00:34:22,720 --> 00:34:24,460 ‫then we make it to all the way 704 00:34:24,460 --> 00:34:26,750 ‫to the end of the middleware function, 705 00:34:26,750 --> 00:34:30,640 ‫where we then assign the currentUser to request.user 706 00:34:30,640 --> 00:34:33,860 ‫so that we can then use it in a next middleware function. 707 00:34:33,860 --> 00:34:34,693 ‫Okay? 708 00:34:34,693 --> 00:34:37,030 ‫Because remember, this request object, 709 00:34:37,030 --> 00:34:38,950 ‫this is the one that travels, basically, 710 00:34:38,950 --> 00:34:40,660 ‫from middleware to middleware. 711 00:34:40,660 --> 00:34:42,330 ‫And so, if we want to pass data 712 00:34:42,330 --> 00:34:44,600 ‫from one middleware to the next one, 713 00:34:44,600 --> 00:34:47,860 ‫then we can simply put some stuff on the request object, 714 00:34:47,860 --> 00:34:51,220 ‫and then that data will be available at a later point. 715 00:34:51,220 --> 00:34:52,053 ‫All right. 716 00:34:52,053 --> 00:34:52,886 ‫So, that's it. 717 00:34:52,886 --> 00:34:54,560 ‫This is a very sophisticated 718 00:34:54,560 --> 00:34:58,300 ‫and very complete route-protecting algorithm, basically, 719 00:34:58,300 --> 00:34:59,740 ‫but I think it's really important 720 00:34:59,740 --> 00:35:02,820 ‫to do it as well as we can. 721 00:35:02,820 --> 00:35:04,990 ‫Anyway, glad to see that you made it 722 00:35:04,990 --> 00:35:07,050 ‫to the end of this big video, 723 00:35:07,050 --> 00:35:09,183 ‫and I'll see you in the next one.