1 00:00:00,870 --> 00:00:05,790 In the less sexually defined serialise user and I don't think I need to really review what's going on 2 00:00:05,790 --> 00:00:08,890 there because I just repeated myself like three times in a row probably. 3 00:00:09,120 --> 00:00:14,670 So the next thing we have to do is define a very similar function called De serialise user in which 4 00:00:14,670 --> 00:00:20,610 we are going to take the ID that we had previously stuffed in the cookie and turn it back into an actual 5 00:00:20,610 --> 00:00:21,990 user model. 6 00:00:22,080 --> 00:00:28,350 So very similar way of defining the second function we're going to say at passport dot de serialise 7 00:00:28,770 --> 00:00:29,760 user. 8 00:00:30,090 --> 00:00:33,630 And then we're going to pass an arrow function into there as well. 9 00:00:33,630 --> 00:00:38,700 Now I want to tell you very quickly please make sure that you check your spelling on serialise user 10 00:00:38,790 --> 00:00:40,430 and serialise user. 11 00:00:40,470 --> 00:00:43,240 Very easy to make typos on both these. 12 00:00:43,470 --> 00:00:49,470 If you see some error in your server eventually that says like DC relies user is not a function that 13 00:00:49,470 --> 00:00:53,720 means you almost definitely made a typo on one of these. 14 00:00:54,000 --> 00:00:56,380 So do you serialize user takes a function. 15 00:00:56,400 --> 00:01:03,390 The first argument is the exact token that we had previously stuffed into a cookie and for us that is 16 00:01:03,390 --> 00:01:04,520 the user's ID. 17 00:01:04,680 --> 00:01:10,170 So we had previously stuff this into the cookie when DC realized user is called We get whatever had 18 00:01:10,170 --> 00:01:11,440 been in the cookie. 19 00:01:11,670 --> 00:01:15,780 And for us that is going to be the ID the user's ID. 20 00:01:15,780 --> 00:01:17,820 So the first argument is the ID. 21 00:01:17,820 --> 00:01:23,460 The second argument is the done function which we have to call after we have successfully turned the 22 00:01:23,460 --> 00:01:26,070 ID back into a user. 23 00:01:26,070 --> 00:01:26,620 OK. 24 00:01:26,940 --> 00:01:32,360 So remember user up here was a user model instance it was a mongoose model. 25 00:01:32,460 --> 00:01:35,710 We turned it into an ID and now we're doing the exact opposite. 26 00:01:35,720 --> 00:01:40,490 We are going to turn an ID into a mongoose model instance. 27 00:01:40,500 --> 00:01:46,410 So in other words we want to search over our big old collection of all of our different users that exist 28 00:01:46,410 --> 00:01:47,730 inside of our database. 29 00:01:48,000 --> 00:01:55,620 And after we find a very particular user We will then return a rule called done with that user so that 30 00:01:55,620 --> 00:01:57,310 looks like in practice. 31 00:01:57,480 --> 00:02:03,060 First off because we want to do a search or a query over our whole collection of users remember weve 32 00:02:03,060 --> 00:02:11,340 done this previously and for that we use our model class which is capital-T you user will say user Daut 33 00:02:11,550 --> 00:02:14,520 find by ID. 34 00:02:14,520 --> 00:02:19,680 So we had previously issued a query by using the Find the one function down here. 35 00:02:20,100 --> 00:02:25,800 So find one allowed us to pass in some search criteria that return the very first record that match 36 00:02:25,800 --> 00:02:33,810 that criteria another query that we can use is find by ID we pass in the ID of the record that we want 37 00:02:33,810 --> 00:02:37,780 to find to this function like the. 38 00:02:38,100 --> 00:02:44,190 Now remember any time we access our Mongo database no matter what it is always an asynchronous action 39 00:02:44,240 --> 00:02:50,300 and to deal with this we have to assume that it returns a promise that will be resolved after a user 40 00:02:50,300 --> 00:02:57,500 with the given ID is found inside of here will change on it then which will be called with the user 41 00:02:57,500 --> 00:02:58,610 model. 42 00:02:59,390 --> 00:03:05,510 So whatever we just pulled out of the database right there and then we will call done with that user 43 00:03:05,510 --> 00:03:07,390 that we just fetched out the database. 44 00:03:07,710 --> 00:03:12,240 So I will say done and remember done always takes an air object if one exists. 45 00:03:12,580 --> 00:03:15,970 So it will say you know everything probably worked OK. 46 00:03:16,130 --> 00:03:16,880 No. 47 00:03:17,180 --> 00:03:23,150 And then as the second argument we pass in the user that we just pulled out okay. 48 00:03:23,210 --> 00:03:24,850 So thats pretty much it. 49 00:03:24,860 --> 00:03:30,950 So we now have the ability to take our user model and put some identifying piece of information into 50 00:03:30,950 --> 00:03:37,560 the cookie and then pull it back out and turn it back into a user at some point in the future. 51 00:03:37,560 --> 00:03:41,830 Now I had said that all this cookie stuff was the last step and it really is. 52 00:03:41,840 --> 00:03:48,110 So to really close this stuff out we cant just define serialise user and serialize user we have to also 53 00:03:48,110 --> 00:03:54,660 instruct the passport that we want it to manage all of our authentication by using a cookie. 54 00:03:54,680 --> 00:04:01,550 So remember a passport is overall is just very general very basic set of helpers for handling authentication. 55 00:04:01,580 --> 00:04:07,310 It has many different ways of keeping track of a user one of which is making use of cookies. 56 00:04:07,310 --> 00:04:14,030 So the last thing we have to do is make sure that passport is aware that it needs to make use of cookies 57 00:04:14,330 --> 00:04:17,090 to keep track of the currently signed in user. 58 00:04:17,450 --> 00:04:22,130 So last we have to do we're going to take care of that in the next section and we will be able to test 59 00:04:22,130 --> 00:04:24,570 out our entire authentication flow. 60 00:04:24,830 --> 00:04:27,500 So quick pause and I'll see you in the next section.