1 00:00:00,580 --> 00:00:04,230 In the last section we finished up our Google strategy callback function. 2 00:00:04,230 --> 00:00:08,280 Now I know that we've been talking about authentication for quite a bit but I've got very good news 3 00:00:08,280 --> 00:00:08,840 for you. 4 00:00:08,940 --> 00:00:13,170 We are really on the very last arc or the last big step that we have to be working on. 5 00:00:13,290 --> 00:00:17,400 So we're almost finished and at the very end we'll do a nice review to talk about everything that we've 6 00:00:17,400 --> 00:00:18,740 accomplished here. 7 00:00:18,750 --> 00:00:24,630 I imagine that this callback function that we just put together is probably one of the more kind of 8 00:00:25,020 --> 00:00:27,330 I don't know complicated things that we've done so far. 9 00:00:27,330 --> 00:00:28,950 Like what is this thing's purpose. 10 00:00:28,950 --> 00:00:32,820 Why are we finding a user what's really going on with that at all. 11 00:00:32,820 --> 00:00:38,040 Trust me as soon as we finish up the flow it will be a lot more obvious why we are going through all 12 00:00:38,040 --> 00:00:39,040 this trouble right here. 13 00:00:39,090 --> 00:00:40,210 So we're almost there. 14 00:00:40,260 --> 00:00:45,030 Soon as we get to the end I know without a doubt that a lot of stuff will kind of reveal itself and 15 00:00:45,030 --> 00:00:47,680 suddenly become a lot more clear. 16 00:00:47,730 --> 00:00:49,930 So we have to figure out what we need to work on next. 17 00:00:50,010 --> 00:00:56,370 Let's go back to a diagram that kind of maps out our progress and we'll get a better sense of what we 18 00:00:56,370 --> 00:00:58,690 need to do to wrap things up. 19 00:00:58,740 --> 00:01:01,170 So we looked at this diagram previously very briefly. 20 00:01:01,290 --> 00:01:06,510 Remember that the purpose of this diagram was to communicate what happens when user signs into our application 21 00:01:06,930 --> 00:01:09,730 signs out and then comes back to sign in again. 22 00:01:09,850 --> 00:01:12,880 Now I want to zoom in on one very particular step here. 23 00:01:14,530 --> 00:01:20,200 So here we are at the top we had said that a user would go through our flow and they would come to our 24 00:01:20,200 --> 00:01:22,660 server with their Google profile. 25 00:01:22,780 --> 00:01:29,020 It was then up to us to take that google profile and either create a new record representing this person 26 00:01:29,050 --> 00:01:34,930 inside the database or retrieve an existing record that says that they are them and that is exactly 27 00:01:35,170 --> 00:01:37,270 what we just did in this callback function. 28 00:01:37,270 --> 00:01:38,500 In the last section or two. 29 00:01:38,530 --> 00:01:40,380 So that's what we just did. 30 00:01:40,450 --> 00:01:45,730 Now that we successfully have either created or retrieved a record representing this user out of our 31 00:01:45,730 --> 00:01:49,030 database we now are moving on to this step right here. 32 00:01:49,030 --> 00:01:50,830 And so this is the last arc. 33 00:01:50,830 --> 00:01:53,590 This is the last big thing that we have to finish up. 34 00:01:53,650 --> 00:01:56,590 We have to somehow take this user model. 35 00:01:56,740 --> 00:02:02,740 So take this thing this user record right here and generate some identifying piece of information and 36 00:02:02,740 --> 00:02:07,840 pass it to the user in a cookie that will then be provided in any follow up request. 37 00:02:07,840 --> 00:02:09,390 Back to our server. 38 00:02:09,430 --> 00:02:11,980 So this is a step that we are now going to work on. 39 00:02:11,980 --> 00:02:15,460 Last thing we have to do now that is both good news and bad news. 40 00:02:15,490 --> 00:02:17,750 The good news is it's the last thing we have to do. 41 00:02:17,770 --> 00:02:23,230 The bad news is this is a kind of complicated step right here but I'm going to do my best to make sure 42 00:02:23,230 --> 00:02:24,420 that we get to it quickly. 43 00:02:24,430 --> 00:02:30,850 But with still covering it in adequate detail we're now going to look at one more diagram that's going 44 00:02:30,850 --> 00:02:35,670 to help us better understand exactly how we're going to deal with this cookie stuff right here. 45 00:02:35,770 --> 00:02:41,170 This is let me say I had time this is another location with passport where it feels kind of like you 46 00:02:41,170 --> 00:02:44,820 don't really have a good sense of the big picture with passport. 47 00:02:45,040 --> 00:02:46,950 Remember how we spoke about that several times. 48 00:02:46,990 --> 00:02:52,450 Sometimes with passport it feels like you're just like kind of reaching in at these very specific locations 49 00:02:52,710 --> 00:02:57,730 and writing just a little snippet of code without really having a great sense of what it is doing with 50 00:02:57,730 --> 00:02:59,320 passport in the big picture. 51 00:02:59,590 --> 00:03:04,660 So rather than just adding in the code that does this right here I want to give you a really good idea 52 00:03:04,720 --> 00:03:07,350 of what the code we're going to write is going to do. 53 00:03:07,730 --> 00:03:11,450 So let's check out one more diagram not that one. 54 00:03:11,560 --> 00:03:14,860 This one this one here we go. 55 00:03:15,490 --> 00:03:15,740 OK. 56 00:03:15,760 --> 00:03:20,560 So essentially the same diagram as what we were just looking at but I'm not showing the Mongo database 57 00:03:20,590 --> 00:03:21,770 over here anymore. 58 00:03:22,030 --> 00:03:26,560 Now the process that we're going to walk through is essentially exactly what I just described to you 59 00:03:26,560 --> 00:03:31,810 in the last slide or last diagram but I've added it in some more terminology that's going to help us 60 00:03:31,870 --> 00:03:34,540 understand the code that we're going to write a little better. 61 00:03:34,600 --> 00:03:36,290 So let's get through this. 62 00:03:36,660 --> 00:03:37,810 Inside a browser. 63 00:03:37,810 --> 00:03:40,990 Someone says OK I want to log into this application. 64 00:03:40,990 --> 00:03:45,830 They go through the water flow and then they come back to the server with the new Google profile in 65 00:03:45,840 --> 00:03:46,530 hand. 66 00:03:46,840 --> 00:03:50,540 So that says essentially I want to log in here's my Google profile. 67 00:03:50,820 --> 00:03:58,000 Our server then says OK we're going to run this Google strategy callback function right here and we're 68 00:03:58,000 --> 00:04:03,700 going to process that profile that we just got from you and you and I know that we really got it from 69 00:04:03,700 --> 00:04:07,310 google but you know hey let's just imagine that these are provided to us. 70 00:04:07,450 --> 00:04:12,490 So let's imagine that this user has already logged into our application previously. 71 00:04:12,490 --> 00:04:19,600 So there is a record inside of our users collection that says hey it has the same profile ID as the 72 00:04:19,600 --> 00:04:20,640 Google profile. 73 00:04:20,680 --> 00:04:22,450 That was just passed to us. 74 00:04:22,660 --> 00:04:28,480 So the server is going to say OK looks like you've got the same Google Profile ID as User 1 2:59 3 from 75 00:04:28,480 --> 00:04:29,680 our database. 76 00:04:29,680 --> 00:04:36,420 I need to give you some identifying token that says you are without a doubt user. 77 00:04:36,430 --> 00:04:42,770 One two three and this token will identify you on any follow up request that is made to our servers. 78 00:04:42,790 --> 00:04:48,100 So here is how we're going to generate that little token or that little identifying piece of information 79 00:04:48,910 --> 00:04:57,520 we're going to define a function called serialise user serialise user is going to be automatically called 80 00:04:57,550 --> 00:05:03,460 by passport with our user model that we just fetched during this step right here. 81 00:05:03,500 --> 00:05:09,910 We're going to use that user model to generate our identifying piece of user information and after we 82 00:05:09,910 --> 00:05:16,600 do that we'll pass that identifying piece of information back to passport and then passport will automatically 83 00:05:16,600 --> 00:05:20,050 stuff that little token into the user's cookie for us. 84 00:05:20,200 --> 00:05:20,750 OK. 85 00:05:20,920 --> 00:05:26,540 So essentially what I just described is exactly the same as what we've been saying all along. 86 00:05:26,740 --> 00:05:28,710 We generate some identifying token. 87 00:05:28,710 --> 00:05:30,110 Stick it in the user's cookie. 88 00:05:30,310 --> 00:05:34,020 All you've done now is giving you some very precise terminology. 89 00:05:34,060 --> 00:05:39,340 I've said that we are going to define a function called serialise user that function is going to be 90 00:05:39,700 --> 00:05:43,840 called with our user model that we just fetched during the step right here. 91 00:05:43,840 --> 00:05:48,170 So nothing's really changed against what we've been talking about previously. 92 00:05:48,190 --> 00:05:51,230 We've we're just going into greater detail at this point. 93 00:05:51,910 --> 00:05:52,170 OK. 94 00:05:52,180 --> 00:05:54,330 So let's imagine that we get that token. 95 00:05:54,340 --> 00:05:55,360 We stuffed it in the cookie. 96 00:05:55,360 --> 00:05:57,300 It goes back to the user's browser. 97 00:05:57,550 --> 00:05:59,200 And now here's the key. 98 00:05:59,590 --> 00:06:02,010 Here's the real mystery at the end of the day. 99 00:06:02,050 --> 00:06:03,860 Everything being answer right now. 100 00:06:04,060 --> 00:06:08,710 Once the user decides that they want to make some type of follow up request to us and ask for like a 101 00:06:08,710 --> 00:06:13,610 list of posts or a list of surveys or a list of whatever they're going to make some request. 102 00:06:13,690 --> 00:06:19,680 From the browser back to our server and when they make that request the cookie will be automatically 103 00:06:19,680 --> 00:06:22,760 added in the request by the browser. 104 00:06:22,920 --> 00:06:25,390 You and I are then going to. 105 00:06:25,470 --> 00:06:32,100 Well to be precise passport is going to take that identifying piece of information from the cookie and 106 00:06:32,100 --> 00:06:39,120 then pass it into a second function that you and I are going to define called De serialise user in which 107 00:06:39,120 --> 00:06:44,700 we're going to take that identifying piece of information and turn it back into a user model that uniquely 108 00:06:44,700 --> 00:06:46,560 identifies this user. 109 00:06:46,560 --> 00:06:52,410 And so after the cookie gets passed or after that token to be precise gets passed into the serialise 110 00:06:52,410 --> 00:06:56,280 user and we somehow figure out what user that is. 111 00:06:56,370 --> 00:07:00,170 We then pass that back to passport and then we say Ah fantastic. 112 00:07:00,170 --> 00:07:01,430 It looks like this is user. 113 00:07:01,500 --> 00:07:02,550 One two three. 114 00:07:02,580 --> 00:07:04,160 They're coming back to us. 115 00:07:04,310 --> 00:07:05,450 They're authenticated. 116 00:07:05,520 --> 00:07:07,970 Let's give them the list of posts that belong to them. 117 00:07:08,160 --> 00:07:09,020 OK. 118 00:07:09,630 --> 00:07:10,460 So that's pretty much it. 119 00:07:10,470 --> 00:07:16,380 Our job right now is to define the functions serialise user Andie's serialise user. 120 00:07:16,560 --> 00:07:21,450 And the purpose of each of these is to take a user model that was sourced from this step right here. 121 00:07:21,480 --> 00:07:28,170 What we just did like two seconds ago and generate some little token out of it that will be stuffed 122 00:07:28,230 --> 00:07:33,960 into the cookie and then on any follow up request we're going to take that took a token pass it into 123 00:07:33,960 --> 00:07:38,760 the serialise user at which point we will turn it back into a user model. 124 00:07:38,880 --> 00:07:41,410 So let's get to it in this section. 125 00:07:41,430 --> 00:07:46,710 We're going to take care of serialise user because it is a little bit easier to handle than the second 126 00:07:46,710 --> 00:07:47,500 one. 127 00:07:47,730 --> 00:07:49,860 So I'm going to change back to my code editor. 128 00:07:50,100 --> 00:07:52,150 I'm still inside of my passport. 129 00:07:52,230 --> 00:07:54,670 Yes file inside of here. 130 00:07:54,720 --> 00:08:04,750 Right underneath our User class declaration right here we are going to call passport dot serialise user. 131 00:08:04,770 --> 00:08:09,810 Now I said that we are going to define this function to be precise We're going to define a function 132 00:08:09,870 --> 00:08:12,020 and pass it to serialize user. 133 00:08:12,270 --> 00:08:20,450 So this is a function we are going to define an arrow function and pass it to serialize user like za. 134 00:08:20,730 --> 00:08:24,870 Now the first argument to serialize user is our user model. 135 00:08:25,020 --> 00:08:28,120 And the second is the done argument. 136 00:08:28,140 --> 00:08:29,700 I don't want to look at. 137 00:08:30,340 --> 00:08:31,860 So user model right here. 138 00:08:31,860 --> 00:08:37,020 I know that we've seen like the word user floating around so much at this point in time you know what 139 00:08:37,020 --> 00:08:40,580 does this actually mean right here what user is this. 140 00:08:40,620 --> 00:08:47,820 So remember whenever the user comes from the flow the profile goes into that Google strategy callback. 141 00:08:47,820 --> 00:08:54,330 The thing that we were just working on in the last two sections from that callback we either retrieve 142 00:08:54,330 --> 00:08:59,410 a user model or a user instance out of our Mago database or we create a new one. 143 00:08:59,410 --> 00:09:04,860 So that is what we were just doing two seconds ago inside of this aero function right here and at the 144 00:09:04,860 --> 00:09:10,480 end of the day we called that done call back with that user model from the database. 145 00:09:10,710 --> 00:09:15,270 This user model that we were returning right here this user instance this object that represents the 146 00:09:15,270 --> 00:09:21,570 user is exactly what is passed to serialize user as this first argument. 147 00:09:21,570 --> 00:09:26,960 So this right here is whatever we just pulled out of the database two seconds ago. 148 00:09:27,540 --> 00:09:34,920 So now it is our job to take that model and somehow generate a identifying piece of information from 149 00:09:34,920 --> 00:09:41,400 it and return it from this function and it will then be used by passport to set up a cookie for us. 150 00:09:41,430 --> 00:09:42,530 So how are we to do that. 151 00:09:42,570 --> 00:09:46,110 Well we're going to put the code down for it and we'll talk about exactly what's going on because this 152 00:09:46,110 --> 00:09:50,560 is going to be like probably the last little piece of confusing code in this whole application. 153 00:09:50,610 --> 00:09:54,740 So we're going to call done with the first argument of no. 154 00:09:55,230 --> 00:10:01,620 And then a second argument of user id so done is a callback we've kind of already established that in 155 00:10:01,620 --> 00:10:07,350 the past that is a somewhat common pattern that we see a lot with passports done as a callback that 156 00:10:07,350 --> 00:10:12,550 we have to call after we have done some work of nudging passport along. 157 00:10:12,690 --> 00:10:19,700 The first argument to done is an air object if one exists or if we ran into any error during this process. 158 00:10:19,710 --> 00:10:23,010 Now for us this is a very simple very straightforward process. 159 00:10:23,010 --> 00:10:25,480 So I really never expect any errors to occur. 160 00:10:25,560 --> 00:10:28,980 So we just say no no there was no air here nothing went wrong. 161 00:10:29,000 --> 00:10:30,140 Everything is fine. 162 00:10:30,540 --> 00:10:36,330 And then here is that identifying piece of information that is going to identify the user and follow 163 00:10:36,330 --> 00:10:37,420 up requests. 164 00:10:37,470 --> 00:10:40,590 It is called user dot I.D.. 165 00:10:40,710 --> 00:10:45,980 So again this is probably the last confusing thing that we really have to figure out. 166 00:10:46,050 --> 00:10:51,210 Now the reason that I say this is confusing is because we've been talking nonstop inside of our Google 167 00:10:51,210 --> 00:10:55,320 strategy right here about this Google Profile I.D.. 168 00:10:55,320 --> 00:10:59,610 We've been saying profile I.D. over and over and over again. 169 00:10:59,730 --> 00:11:05,240 The reason this is confusing is that this idea right here is not the profile ID. 170 00:11:05,460 --> 00:11:06,470 So let's expand on that. 171 00:11:06,480 --> 00:11:07,680 Let's talk about why that is. 172 00:11:07,680 --> 00:11:14,210 We'll talk about exactly what this I.D. right here is going to change back over to my in-law database 173 00:11:14,330 --> 00:11:15,820 Here's my user's collection. 174 00:11:15,980 --> 00:11:18,560 And here's that record that we had previously created. 175 00:11:18,560 --> 00:11:23,660 So this is exactly what exists inside of our users collection right now. 176 00:11:23,720 --> 00:11:24,990 It has a Google ID. 177 00:11:25,100 --> 00:11:25,580 Yes. 178 00:11:25,580 --> 00:11:26,660 That is the profile ID. 179 00:11:26,690 --> 00:11:31,270 We have been making use of that we have been making news that a ton so far. 180 00:11:31,550 --> 00:11:39,510 But remember that this record also has this underscore ID property this string right here of 5 9 5 F 181 00:11:39,520 --> 00:11:46,810 C is a unique identifier that was automatically generated by Mongo and assigned to this record. 182 00:11:46,820 --> 00:11:55,780 So when we see user ID right here this user ID right here this is a shortcut to this idea right here. 183 00:11:56,210 --> 00:11:56,830 OK. 184 00:11:57,170 --> 00:12:04,310 So in other words to uniquely identify our user inside of our cookie we are not making use of the profile 185 00:12:04,310 --> 00:12:10,030 ID we were making use of the ID that is assigned to this record by Monga. 186 00:12:10,040 --> 00:12:14,660 Now if you're curious why we are doing that you know why we're using this Mongo identifier rather than 187 00:12:14,660 --> 00:12:16,130 the profile ID. 188 00:12:16,130 --> 00:12:23,740 The reason is that we can very very easily be making use of multiple different authentication providers. 189 00:12:23,750 --> 00:12:26,850 Right we might have Google sign in and Facebook and linked in. 190 00:12:27,080 --> 00:12:32,490 And if we have all three of those we cannot always assume that a user has a Google ID. 191 00:12:32,630 --> 00:12:33,180 They have my. 192 00:12:33,200 --> 00:12:36,980 They might have signed it with Facebook where they might have signed in with Linked-In or something 193 00:12:36,980 --> 00:12:37,550 else. 194 00:12:37,730 --> 00:12:43,700 So we can't always assume that everyone will have a Google ID but we can assume that every user user 195 00:12:43,700 --> 00:12:47,640 will have an ID automatically generated by Mongo. 196 00:12:47,870 --> 00:12:51,350 Now just two more things I want to say very quickly about this because I know this is turning up really 197 00:12:51,350 --> 00:12:52,250 long. 198 00:12:52,250 --> 00:12:57,830 First off I said that this was a shortcut to that Id user ID right here just to be clear like yes that 199 00:12:57,830 --> 00:13:02,090 is a shortcut to reference the ID that is generated by Mongo. 200 00:13:02,090 --> 00:13:08,260 We do not have to look at underscore ID dot dollar sign o id or anything like that. 201 00:13:08,360 --> 00:13:15,320 We can just get access to this ID inside of our server side code by saying user ID and that automatically 202 00:13:15,320 --> 00:13:17,640 references this exact string right here. 203 00:13:17,660 --> 00:13:26,210 So that's thing number one thing number two is just to further break down why we are using the profile 204 00:13:26,210 --> 00:13:26,570 ID. 205 00:13:26,570 --> 00:13:32,960 In one case and the user model ID in the other case just to be sure that make sure its really clear 206 00:13:32,960 --> 00:13:33,370 here. 207 00:13:33,410 --> 00:13:37,940 You know exactly what I just said it's because we might have multiple different providers but a different 208 00:13:37,940 --> 00:13:44,930 way of thinking about it is that the Google lava flow is providing us with a profile ID which is specifically 209 00:13:44,960 --> 00:13:50,900 for the portion of our authentication flow that identifies a user who has first attempting to sign it 210 00:13:51,560 --> 00:13:53,390 after the user has signed in. 211 00:13:53,540 --> 00:13:56,110 We don't care about the profile ID anymore at all. 212 00:13:56,180 --> 00:14:02,960 Doesn't matter after the user has signed in using that profile ID we only care about our own internal 213 00:14:02,960 --> 00:14:07,650 ID which is the Mongo database ID that we are now using. 214 00:14:07,760 --> 00:14:08,090 OK. 215 00:14:08,120 --> 00:14:13,340 So just to make sure that its clear the profile idea is for like one distinct stage of our application 216 00:14:13,820 --> 00:14:17,550 and then after that all we really care about is the user ID. 217 00:14:18,200 --> 00:14:19,050 OK. 218 00:14:19,430 --> 00:14:25,120 So thats probably enough way more discussion than you ever wanted for three little lines of code. 219 00:14:25,400 --> 00:14:29,180 But like I said this was the last big challenge right here. 220 00:14:29,300 --> 00:14:38,510 So we have now defined a function that allows us to take a user model and generate some unique identifying 221 00:14:38,510 --> 00:14:43,630 piece of information from it and then a passport will eventually stuff that into a cookie. 222 00:14:43,880 --> 00:14:45,800 So were going to take a quick break right now. 223 00:14:45,830 --> 00:14:50,810 We're going to come back and then we're going to define the second function called deeth serialise user 224 00:14:51,290 --> 00:14:57,080 in which we take that unique identifier that was placed inside the cookie and turn it back into an actual 225 00:14:57,080 --> 00:14:58,460 user model. 226 00:14:58,460 --> 00:15:01,330 So let's take a quick break and continue in the next section.