1 00:00:00,690 --> 00:00:05,100 In the last section we finished wiring up our authentication flow by enabling cookies inside of our 2 00:00:05,100 --> 00:00:10,910 application and then essentially telling passport to use cookies to manage our authentication. 3 00:00:10,920 --> 00:00:16,890 So at this point you might be sitting there thinking OK like we are authenticated I guess but what does 4 00:00:16,890 --> 00:00:17,950 that really get us. 5 00:00:18,000 --> 00:00:19,480 Like what do we care now. 6 00:00:19,560 --> 00:00:21,410 Why is this relevant at all. 7 00:00:21,630 --> 00:00:27,540 So let's look at a quick diagram that's going to tell us exactly what the end result of all this authentication 8 00:00:27,540 --> 00:00:28,600 stuff is. 9 00:00:28,650 --> 00:00:33,360 And then from that diagram We'll also get a better sense of how we will test out our authentication 10 00:00:33,360 --> 00:00:36,000 flow to make sure that it is working. 11 00:00:36,030 --> 00:00:39,150 So I to flip over to a diagram really quick. 12 00:00:39,300 --> 00:00:39,840 OK. 13 00:00:40,080 --> 00:00:46,080 So this is essentially the flow that is going to occur any single time a user makes a request to our 14 00:00:46,080 --> 00:00:49,300 application after having gone through the waterflow. 15 00:00:49,800 --> 00:00:52,260 So some request is going to come in from the browser. 16 00:00:52,380 --> 00:00:54,010 So we take that request. 17 00:00:54,120 --> 00:00:59,610 That request is going to be passed to that cookie session thing which is going to automatically extract 18 00:00:59,910 --> 00:01:06,210 all the data out of that cookie and it will encrypt the data that exists inside of there that data is 19 00:01:06,210 --> 00:01:12,060 then passed on to passports which pulls that user ID out of the cookie data. 20 00:01:12,060 --> 00:01:19,140 The idea is then passed on to our serialise user function where we are currently taking that ID and 21 00:01:19,140 --> 00:01:24,790 turning it into a user model instance and then the end result of all this like the end product. 22 00:01:24,930 --> 00:01:29,340 The thing that we were going through all this work forward to just make this happen. 23 00:01:29,400 --> 00:01:36,750 The very end result is that the user model instance that we returned from DC relies user is added to 24 00:01:36,750 --> 00:01:40,570 the request object as rec dot user. 25 00:01:40,610 --> 00:01:46,020 And remember weve seen the word rack a couple of times inside of our application rack is the short for 26 00:01:46,050 --> 00:01:50,650 the request object that is passed into any express route handler. 27 00:01:50,670 --> 00:01:58,050 So after this entire automated process wraps up for every request that comes in that request that just 28 00:01:58,050 --> 00:02:03,810 got modified with recked user is then sent on to whatever route handler is supposed to deal with that 29 00:02:03,810 --> 00:02:04,830 request. 30 00:02:04,860 --> 00:02:11,130 So in order to really test this thing out we are going to add a new route handler inside of our application 31 00:02:11,460 --> 00:02:16,580 whose sole purpose is to kind of inspect this redcoat user property. 32 00:02:16,770 --> 00:02:22,650 We'll look at that user property and if our user model exists on that thing that means that authentication 33 00:02:22,650 --> 00:02:24,310 must be working inside Iraq. 34 00:02:24,530 --> 00:02:24,820 OK. 35 00:02:24,840 --> 00:02:26,720 So that's how we're going to test this. 36 00:02:26,880 --> 00:02:28,880 So let's define a new route handler. 37 00:02:29,190 --> 00:02:33,320 I'm going to find my routes throughout start G-S file. 38 00:02:33,780 --> 00:02:39,530 So here is where we have our two handlers right now for handling the process underneath. 39 00:02:39,630 --> 00:02:40,650 Both of these. 40 00:02:40,920 --> 00:02:48,180 I'm going to add a third handler so we'll say whenever someone makes a get request to our app and we'll 41 00:02:48,180 --> 00:02:54,270 give it the route of slash API slash current user and I'm totally making up this route right here by 42 00:02:54,270 --> 00:02:54,660 the way. 43 00:02:54,660 --> 00:02:58,220 Remember we can define routes that are called anything we want. 44 00:02:58,290 --> 00:03:01,500 I'm just kind of thinking about our application the future. 45 00:03:01,500 --> 00:03:06,930 I'm assuming that we might want to have some API route that returns whoever's currently logged into 46 00:03:06,930 --> 00:03:08,850 the application. 47 00:03:08,850 --> 00:03:14,250 Now the second argument we pass our arrow function though will be automatically called Whenever someone 48 00:03:14,250 --> 00:03:17,610 makes a request to this route right here. 49 00:03:17,700 --> 00:03:22,700 Remember that the arguments for this function are the wreck and rez objects. 50 00:03:22,950 --> 00:03:28,460 Recked represents the incoming request rez represents the outgoing response. 51 00:03:28,560 --> 00:03:29,680 So all we're going to do here. 52 00:03:29,700 --> 00:03:31,510 We're going to keep it nice and easy. 53 00:03:31,530 --> 00:03:34,430 We're going to just immediately send back. 54 00:03:34,540 --> 00:03:35,560 Redstart send. 55 00:03:35,640 --> 00:03:37,630 So just make an immediate response. 56 00:03:37,650 --> 00:03:45,870 And we want to send back rec dot user so this will test to make sure that someone who has already gone 57 00:03:45,870 --> 00:03:53,220 to the flow and in theory logged into our application can now you know hey get access to the user. 58 00:03:53,250 --> 00:03:54,040 That's pretty much it. 59 00:03:54,180 --> 00:03:54,450 OK. 60 00:03:54,450 --> 00:03:55,740 Enough talking. 61 00:03:55,740 --> 00:03:58,110 I've spoken enough so far about authentication. 62 00:03:58,110 --> 00:03:59,930 It's time to just test this thing out. 63 00:04:00,100 --> 00:04:02,110 So I get it changed back over to my server. 64 00:04:02,130 --> 00:04:07,390 I going to verify that it is running and I do not have any errors outside of those two deprecation warnings. 65 00:04:07,410 --> 00:04:08,820 So everything looks good. 66 00:04:08,850 --> 00:04:11,010 I will then change back over to my browser. 67 00:04:11,310 --> 00:04:16,380 Now we have to go through the authentication flow one more time because remember we only just added 68 00:04:16,470 --> 00:04:19,320 on all this additional logic around cookies. 69 00:04:19,320 --> 00:04:24,000 So we have to go through the flow one more time to get our cookies set up and all that kind of jazz. 70 00:04:24,030 --> 00:04:31,130 So open up a new tab or go to a local host Colan 5000 slash off slash Google. 71 00:04:31,290 --> 00:04:35,790 And remember we haven't really added any code yet to really resolve this response. 72 00:04:35,790 --> 00:04:37,550 We will fix that up in just a little bit. 73 00:04:37,710 --> 00:04:42,300 But essentially after we visit this route we're still going to kind of like see an air or have the requests 74 00:04:42,300 --> 00:04:42,900 just hang. 75 00:04:42,900 --> 00:04:44,360 Or something like that. 76 00:04:44,610 --> 00:04:46,110 So we'll visit this route. 77 00:04:46,110 --> 00:04:48,180 So that should kick us over to Google. 78 00:04:48,190 --> 00:04:54,150 It should initialize our cookie it should kick our user ID into the cookie and then return that cookie 79 00:04:54,150 --> 00:04:55,480 to our browser. 80 00:04:55,770 --> 00:05:03,540 So in theory I now have a cookie tied to our application that identifies me as a very particular user. 81 00:05:03,540 --> 00:05:06,210 Now again you see an era peer that's totally fine. 82 00:05:06,360 --> 00:05:06,860 Totally fine. 83 00:05:06,870 --> 00:05:11,980 It's just because we are not properly handling this request but we will fix that up in just a second. 84 00:05:12,000 --> 00:05:16,220 So now I'm considered to be logged in and authenticated to our application. 85 00:05:16,470 --> 00:05:23,120 So the last step to test this out and then open up a second tab and navigate to localhost. 86 00:05:23,310 --> 00:05:33,330 5000 slash API slash current user when I navigate to that route we will go through this flow right here. 87 00:05:33,330 --> 00:05:39,210 The request will come in the cookie session that we just wired up will extract all the data other cookie 88 00:05:39,450 --> 00:05:45,510 passport pulls out the ID that ID is passed to the DC your lies user function that we wrote which turns 89 00:05:45,510 --> 00:05:51,810 the ID into a user and then that user is added to our request object as recked user and the request 90 00:05:51,870 --> 00:05:53,330 goes onto the handler. 91 00:05:53,640 --> 00:06:01,080 So let's give this a shot and hit enter and we get a response of our user model exactly as it exists 92 00:06:01,170 --> 00:06:02,960 inside of our application. 93 00:06:03,000 --> 00:06:09,810 So heres my user ID Here's my google profile ID and then the underscore underscore the property is something 94 00:06:09,810 --> 00:06:13,330 that is maintained by mongoose and its not something we have to worry about. 95 00:06:13,410 --> 00:06:14,920 So thats it. 96 00:06:14,940 --> 00:06:15,770 It works. 97 00:06:15,840 --> 00:06:17,510 Hooray. 98 00:06:18,480 --> 00:06:20,210 I don't know what to say. 99 00:06:20,360 --> 00:06:23,520 That's a lot of work to make authentication happen. 100 00:06:23,610 --> 00:06:25,880 Right now we're not even done. 101 00:06:25,930 --> 00:06:28,790 We don't have the ability to log out yet. 102 00:06:28,840 --> 00:06:32,680 So yes authentication is a lot of work. 103 00:06:32,680 --> 00:06:39,600 There is a lot that goes into it but I hope I pray that now you have a much better sense of what is 104 00:06:39,600 --> 00:06:42,810 going on behind the scenes with all this passport stuff. 105 00:06:43,050 --> 00:06:49,500 And I hope you have a much more solid understanding of how a lot works inside of modern applications. 106 00:06:49,500 --> 00:06:53,590 So we've now got this Google strategy put together right here. 107 00:06:53,640 --> 00:07:00,780 You can go and install a Facebook strategy or a Linked-In or a good hub or any other strategy you want 108 00:07:00,780 --> 00:07:06,960 to use and wire it up to our application in a very similar way to what we just did right here. 109 00:07:06,960 --> 00:07:12,500 Honestly go install the strategy define this callback function and that is all you have to do. 110 00:07:12,660 --> 00:07:17,670 Well there's one more thing you've got to set up these off Google handlers but that's pretty much it. 111 00:07:17,670 --> 00:07:24,750 So once you do that stuff you can add in Facebook authentication linked in get hub all these different 112 00:07:24,750 --> 00:07:30,010 providers with the exact same techniques that we've now established so far in this course. 113 00:07:30,030 --> 00:07:32,330 So I know it has been painful going through this. 114 00:07:32,340 --> 00:07:38,400 I know it has been very long but we have a fantastic new skill now and we really know how to handle 115 00:07:38,430 --> 00:07:40,370 authentication in our application. 116 00:07:40,790 --> 00:07:47,340 Okay so enough of the pep talk we still have obviously a tremendous amount of stuff to do inside of 117 00:07:47,340 --> 00:07:51,400 our application to build this final app that we're trying to get working. 118 00:07:51,420 --> 00:07:53,410 So I want to continue in the next section. 119 00:07:53,430 --> 00:07:57,960 The first thing we're going to do is we're going to add one little piece of logic to allow us to log 120 00:07:57,960 --> 00:08:02,910 out of our application and that will allow us to really test the entire authentication flow from start 121 00:08:02,910 --> 00:08:03,750 to finish. 122 00:08:04,080 --> 00:08:07,960 And then after we talk about how to integrate log out we'll take a break. 123 00:08:08,040 --> 00:08:13,260 We'll come back in the section after that and we'll do that optional discussion about exactly what is 124 00:08:13,260 --> 00:08:15,750 going on with some of this kooky stuff over here. 125 00:08:15,900 --> 00:08:16,400 OK. 126 00:08:16,740 --> 00:08:18,170 So let's get to it.