In the last section we finished up our Google strategy callback function.
Now I know that we've been talking about authentication for quite a bit but I've got very good news
for you.
We are really on the very last arc or the last big step that we have to be working on.
So we're almost finished and at the very end we'll do a nice review to talk about everything that we've
accomplished here.
I imagine that this callback function that we just put together is probably one of the more kind of
I don't know complicated things that we've done so far.
Like what is this thing's purpose.
Why are we finding a user what's really going on with that at all.
Trust me as soon as we finish up the flow it will be a lot more obvious why we are going through all
this trouble right here.
So we're almost there.
Soon as we get to the end I know without a doubt that a lot of stuff will kind of reveal itself and
suddenly become a lot more clear.
So we have to figure out what we need to work on next.
Let's go back to a diagram that kind of maps out our progress and we'll get a better sense of what we
need to do to wrap things up.
So we looked at this diagram previously very briefly.
Remember that the purpose of this diagram was to communicate what happens when user signs into our application
signs out and then comes back to sign in again.
Now I want to zoom in on one very particular step here.
So here we are at the top we had said that a user would go through our flow and they would come to our
server with their Google profile.
It was then up to us to take that google profile and either create a new record representing this person
inside the database or retrieve an existing record that says that they are them and that is exactly
what we just did in this callback function.
In the last section or two.
So that's what we just did.
Now that we successfully have either created or retrieved a record representing this user out of our
database we now are moving on to this step right here.
And so this is the last arc.
This is the last big thing that we have to finish up.
We have to somehow take this user model.
So take this thing this user record right here and generate some identifying piece of information and
pass it to the user in a cookie that will then be provided in any follow up request.
Back to our server.
So this is a step that we are now going to work on.
Last thing we have to do now that is both good news and bad news.
The good news is it's the last thing we have to do.
The bad news is this is a kind of complicated step right here but I'm going to do my best to make sure
that we get to it quickly.
But with still covering it in adequate detail we're now going to look at one more diagram that's going
to help us better understand exactly how we're going to deal with this cookie stuff right here.
This is let me say I had time this is another location with passport where it feels kind of like you
don't really have a good sense of the big picture with passport.
Remember how we spoke about that several times.
Sometimes with passport it feels like you're just like kind of reaching in at these very specific locations
and writing just a little snippet of code without really having a great sense of what it is doing with
passport in the big picture.
So rather than just adding in the code that does this right here I want to give you a really good idea
of what the code we're going to write is going to do.
So let's check out one more diagram not that one.
This one this one here we go.
OK.
So essentially the same diagram as what we were just looking at but I'm not showing the Mongo database
over here anymore.
Now the process that we're going to walk through is essentially exactly what I just described to you
in the last slide or last diagram but I've added it in some more terminology that's going to help us
understand the code that we're going to write a little better.
So let's get through this.
Inside a browser.
Someone says OK I want to log into this application.
They go through the water flow and then they come back to the server with the new Google profile in
hand.
So that says essentially I want to log in here's my Google profile.
Our server then says OK we're going to run this Google strategy callback function right here and we're
going to process that profile that we just got from you and you and I know that we really got it from
google but you know hey let's just imagine that these are provided to us.
So let's imagine that this user has already logged into our application previously.
So there is a record inside of our users collection that says hey it has the same profile ID as the
Google profile.
That was just passed to us.
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
our database.
I need to give you some identifying token that says you are without a doubt user.
One two three and this token will identify you on any follow up request that is made to our servers.
So here is how we're going to generate that little token or that little identifying piece of information
we're going to define a function called serialise user serialise user is going to be automatically called
by passport with our user model that we just fetched during this step right here.
We're going to use that user model to generate our identifying piece of user information and after we
do that we'll pass that identifying piece of information back to passport and then passport will automatically
stuff that little token into the user's cookie for us.
OK.
So essentially what I just described is exactly the same as what we've been saying all along.
We generate some identifying token.
Stick it in the user's cookie.
All you've done now is giving you some very precise terminology.
I've said that we are going to define a function called serialise user that function is going to be
called with our user model that we just fetched during the step right here.
So nothing's really changed against what we've been talking about previously.
We've we're just going into greater detail at this point.
OK.
So let's imagine that we get that token.
We stuffed it in the cookie.
It goes back to the user's browser.
And now here's the key.
Here's the real mystery at the end of the day.
Everything being answer right now.
Once the user decides that they want to make some type of follow up request to us and ask for like a
list of posts or a list of surveys or a list of whatever they're going to make some request.
From the browser back to our server and when they make that request the cookie will be automatically
added in the request by the browser.
You and I are then going to.
Well to be precise passport is going to take that identifying piece of information from the cookie and
then pass it into a second function that you and I are going to define called De serialise user in which
we're going to take that identifying piece of information and turn it back into a user model that uniquely
identifies this user.
And so after the cookie gets passed or after that token to be precise gets passed into the serialise
user and we somehow figure out what user that is.
We then pass that back to passport and then we say Ah fantastic.
It looks like this is user.
One two three.
They're coming back to us.
They're authenticated.
Let's give them the list of posts that belong to them.
OK.
So that's pretty much it.
Our job right now is to define the functions serialise user Andie's serialise user.
And the purpose of each of these is to take a user model that was sourced from this step right here.
What we just did like two seconds ago and generate some little token out of it that will be stuffed
into the cookie and then on any follow up request we're going to take that took a token pass it into
the serialise user at which point we will turn it back into a user model.
So let's get to it in this section.
We're going to take care of serialise user because it is a little bit easier to handle than the second
one.
So I'm going to change back to my code editor.
I'm still inside of my passport.
Yes file inside of here.
Right underneath our User class declaration right here we are going to call passport dot serialise user.
Now I said that we are going to define this function to be precise We're going to define a function
and pass it to serialize user.
So this is a function we are going to define an arrow function and pass it to serialize user like za.
Now the first argument to serialize user is our user model.
And the second is the done argument.
I don't want to look at.
So user model right here.
I know that we've seen like the word user floating around so much at this point in time you know what
does this actually mean right here what user is this.
So remember whenever the user comes from the flow the profile goes into that Google strategy callback.
The thing that we were just working on in the last two sections from that callback we either retrieve
a user model or a user instance out of our Mago database or we create a new one.
So that is what we were just doing two seconds ago inside of this aero function right here and at the
end of the day we called that done call back with that user model from the database.
This user model that we were returning right here this user instance this object that represents the
user is exactly what is passed to serialize user as this first argument.
So this right here is whatever we just pulled out of the database two seconds ago.
So now it is our job to take that model and somehow generate a identifying piece of information from
it and return it from this function and it will then be used by passport to set up a cookie for us.
So how are we to do that.
Well we're going to put the code down for it and we'll talk about exactly what's going on because this
is going to be like probably the last little piece of confusing code in this whole application.
So we're going to call done with the first argument of no.
And then a second argument of user id so done is a callback we've kind of already established that in
the past that is a somewhat common pattern that we see a lot with passports done as a callback that
we have to call after we have done some work of nudging passport along.
The first argument to done is an air object if one exists or if we ran into any error during this process.
Now for us this is a very simple very straightforward process.
So I really never expect any errors to occur.
So we just say no no there was no air here nothing went wrong.
Everything is fine.
And then here is that identifying piece of information that is going to identify the user and follow
up requests.
It is called user dot I.D..
So again this is probably the last confusing thing that we really have to figure out.
Now the reason that I say this is confusing is because we've been talking nonstop inside of our Google
strategy right here about this Google Profile I.D..
We've been saying profile I.D. over and over and over again.
The reason this is confusing is that this idea right here is not the profile ID.
So let's expand on that.
Let's talk about why that is.
We'll talk about exactly what this I.D. right here is going to change back over to my in-law database
Here's my user's collection.
And here's that record that we had previously created.
So this is exactly what exists inside of our users collection right now.
It has a Google ID.
Yes.
That is the profile ID.
We have been making use of that we have been making news that a ton so far.
But remember that this record also has this underscore ID property this string right here of 5 9 5 F
C is a unique identifier that was automatically generated by Mongo and assigned to this record.
So when we see user ID right here this user ID right here this is a shortcut to this idea right here.
OK.
So in other words to uniquely identify our user inside of our cookie we are not making use of the profile
ID we were making use of the ID that is assigned to this record by Monga.
Now if you're curious why we are doing that you know why we're using this Mongo identifier rather than
the profile ID.
The reason is that we can very very easily be making use of multiple different authentication providers.
Right we might have Google sign in and Facebook and linked in.
And if we have all three of those we cannot always assume that a user has a Google ID.
They have my.
They might have signed it with Facebook where they might have signed in with Linked-In or something
else.
So we can't always assume that everyone will have a Google ID but we can assume that every user user
will have an ID automatically generated by Mongo.
Now just two more things I want to say very quickly about this because I know this is turning up really
long.
First off I said that this was a shortcut to that Id user ID right here just to be clear like yes that
is a shortcut to reference the ID that is generated by Mongo.
We do not have to look at underscore ID dot dollar sign o id or anything like that.
We can just get access to this ID inside of our server side code by saying user ID and that automatically
references this exact string right here.
So that's thing number one thing number two is just to further break down why we are using the profile
ID.
In one case and the user model ID in the other case just to be sure that make sure its really clear
here.
You know exactly what I just said it's because we might have multiple different providers but a different
way of thinking about it is that the Google lava flow is providing us with a profile ID which is specifically
for the portion of our authentication flow that identifies a user who has first attempting to sign it
after the user has signed in.
We don't care about the profile ID anymore at all.
Doesn't matter after the user has signed in using that profile ID we only care about our own internal
ID which is the Mongo database ID that we are now using.
OK.
So just to make sure that its clear the profile idea is for like one distinct stage of our application
and then after that all we really care about is the user ID.
OK.
So thats probably enough way more discussion than you ever wanted for three little lines of code.
But like I said this was the last big challenge right here.
So we have now defined a function that allows us to take a user model and generate some unique identifying
piece of information from it and then a passport will eventually stuff that into a cookie.
So were going to take a quick break right now.
We're going to come back and then we're going to define the second function called deeth serialise user
in which we take that unique identifier that was placed inside the cookie and turn it back into an actual
user model.
So let's take a quick break and continue in the next section.