At this point we have completed the main authentication flow and our application in this video we're
going to talk about a couple optional topics and go into greater detail around some areas that we kind
of skimmed through while we were implementing the flow.
So just to be clear completely optional video right now totally optional.
If you're tired of hearing about authentication and if you just want to move on and start working on
the app pauses for you right now.
Continue in the next one.
OK.
Otherwise if you stick around and give you a better sense of a couple of different topics we just very
lightly grazed over.
OK.
So let's get to it.
The first thing we're going to talk about are these out don't use calls that we placed into our index
js file.
About halfway down.
So we have three calls to add don't use and in every case we've passed in some completely different
object to them.
Each of these apps use calls are wiring up what are referred to as middleware inside of our application
middleware our small functions that can be used to modify incoming requests to our app before they are
sent off to route handlers.
So let's look at a diagram that will give us a little bit of a better sense of exactly how this works.
OK.
So we looked at this diagram previously but actually gives us a pretty good idea of what's going on.
Any time a request comes into our application that request is taken and sent into that cookie session
middleware and the two passport middleware is as well.
All three of those middleware.
So all through these right here we'll take that incoming requests and make some very small or minor
adjustments to it.
And so in the context of these three middle whereas we had previously discussed exactly what they did.
Right we had said that cookie session pull some data out of the cook or Pilson did out of the cookie
the passport stuff then pulls the user ID out of that cookie and then some other stuff happens along
there as well.
So again middleware is are all about doing some preprocessing of the incoming requests before they are
sent off to our different route handlers.
As such they are a great location to locate some logic that is common to many different handlers.
And so for our application it's really easy to assume that we might want to authenticate every single
route handler that we have.
You know we might want to know about every single user who's coming into our application.
And so rather than adding some logic at the top of every single handler and saying OK let's like extract
the cookie data and then something something something we can instead just wire up these middleware.
One time and then they will be automatically used for every request that comes into application.
Now your first question in response to that might be well what if I don't want to run these middleware
is around every rat handler handler.
The answer is that's totally fine.
You can wire up your middleware in such a way that there will only be used for a portion of your handlers
if you wish to and we will actually see an example of that very shortly as well.
Now the last thing I want to show you is just one more diagram that'll give you a better sense of middleware
inside of her app.
So we start off at the very top.
We have some requests from the browser coming into our application object that an object is created
by the Express library the request object is then piped into all the different middleware that we have
in our application.
And then they are sent off to the different row handlers that we have registered inside of the handlers.
We do some amount of requests or logic or database stuff whatever it is.
We formulate a response and send it back to whoever made the initial request.
OK.
So middleware is right in there before the routing handlers.
Now believe it or not you've actually learned like probably 90 percent of what is going on with Express
at this point if you understand middleware and you understand the idea behind route handlers that's
really the very major topics.
Now of course express also has a ton of tiny little API and function calls and all that stuff.
But this is really the general architecture of Express that's all there is to it.
It is a very lightweight framework.
OK.
So that's topic number one.
We're now done with that and we're now going to move on to our next topic which is going to give us
a little bit of a better idea of what is going on with this cooking session thing right here.
OK.
So the goal right now is to get a better sense of what the cookie session is doing for us and how it
relates to passport.
Now everything I'm about to tell you is a lot of stuff that I wish someone had told me when I first
got started with the express way long ago.
I really wish someone had just sat me down and spelled all this stuff out.
Clear as crystal because it would have saved me a tremendous amount of time myself so hopefully I can
save you a equal amount of time by giving you a quick spiel about what this cookie session is doing.
OK.
So again the idea here I want to figure out what the cookies is doing.
All right.
That's all we're doing to figure out what it's doing.
We're going to first flip over to our routes all routes are all throughout St. James File.
We're going to find that current user request handler at the very bottom and we're going to make a very
small temporary change to this route handler.
So if you skip over the rest of this video or if you eventually like drop off I can tell you right now
make sure you revert that change the we're about to make.
Very important.
OK make sure you change that back.
I will make the change back myself at the end of this video.
I just want to make sure you do it as well.
So down here I'm going to say restaurants and I'm going to send back instead of recked user I'm going
to send back Reyk dot session like so.
So let's look at what happens now.
I'm going to flip back over to my browser.
I'm going to open up a new tab.
I'm going to make sure that I'm logged in by visiting local Colin 5000 slash off slash Google.
So that's going to log me in.
Yes I get the error right here.
But that's really fine.
I am now considered to be logged in.
And now we're going to go access that route handler that we just change right here.
So I haven't said anything about that session yet.
We'll talk about what it is.
As soon as we test this thing so I'm not going to go to localhost Colan 5000 slash API slash current
user OK.
So this right here is our rec dot session object.
And again remember the purpose of our talk right now I wanted to teach you exactly what that cookie
session thing is doing.
So at this point we have said several times throughout our entire authentication flow we have looked
at that diagram right here and we had said that the incoming request comes in the cookie session middleware
extracts some amount of data and then the passport library somehow pulls the user ID out of that out
of that data.
So let's just kind of like break down this process and really analyze what is going on between these
two libraries.
In reality when we say that the cookie session library extracts the cookie data it does but just to
be crystal clear what really happens is the cookie session library extracts that data out of the cookie
and then assigns it to this rec dot session property so wrecked that session right here contains the
data.
That passport is attempting to store inside of the cookie.
When we then pass that request object onto passport passport is not really looking at that cookie per
se it is looking internally at rec dot session.
So it looks at Red Dot session it pulls it's relevant data out there and then it passes that all onto
serialize user and all that other stuff.
So if we go back to the request that we just made this is the session right here.
You can see very clearly that one piece of data in our session is being managed by passport and that
data that's being managed is an object that has a key of user.
And then this long string right here.
And so you might just recognize this string.
You'll look at it closely.
It's 5 9 5 F C that's mine.
At least yours is probably different.
If I go over to my lab console I'm looking at my users collection right now inside the database and
you'll recognize that the ID of my user record is identical to what we just saw in that session 5 9
5.
FC So if you go back to this diagram right your cookie session takes the data out of the cookie and
assigns it Terek session one of the properties in the session is called passport and inside of that
passport piece of data is the ID that we have been schlepping around from serialise user and serialise
user.
Remember that's where we had put together this stuff that kind of encodes instead of our password.
Yes.
These two things right here which are what encodes the user's ID inside of the cookie.
OK.
So that's just a little bit of a better sense of what the real relation between passport and the cookie
session library or cookie session is like.
Not really inherently passing data to passport.
It's just processing the incoming requests populating that session property right here and then passport
accesses the data that exist on retrocession.
OK.
So that's a little bit more on record duck session at this point.
I'm going to change back over to my author stock js file and I'm going to undo that session change that
we just made a second ago.
I'm going to revert it back over to sending back the current user.
Now that's not all I want to tell you about with cookie session right here because if I just told you
that.
And then you might be sitting there like what Stephen that was really hard for you to figure out.
Well one of the thing that's a little bit more critical with red dots with the cookie session and this
is the part that I really want to communicate to you.
This is the part that was very challenging for me to initially comprehend way long ago when I was picking
up Express.
OK.
So our library that we installed here to manage all the data on our cookie is called cookie session
that's that installed cookie session right here.
Now if you go and look up the documentation around Express and you look up Express's guide on how to
use cookies or how to establish sessions inside of an express application they're actually going to
recommend two different libraries to you.
And so the second thing I want to tell you the thing that like confused me for a while is the difference
between the library that we just used called cookie session and the other library that express recommends
called Express session.
Both of these libraries essentially accomplish the same thing but they do it in a very different fashion.
So we've already got a pretty reasonable sense of what cookie session does.
Right.
This is what we used inside of our application.
We can assign some amount of data to the cookie cookies session as a middleware then takes all the data
out of that cookie and assigns it to the rack session property.
So let's talk about now what the Express session middleware does and why it is so different.
So we're going to figure this out by looking at one more diagram and it might take me just a second
to find it because I know I have so many diagrams.
I think we want 12.
OK.
Here we go.
So sessions with express the thing I want to remind you here is that in all this discussion about making
use of authentication inside of our application and relating that all back to passport we've been saying
nonstop nonstop nonstop.
We wanted to put some identifying piece of information into the user's cookie so that it would be relayed
with every follow up request that the user every makes.
The key difference between the cookie session library and the Express session library is exactly how
that data is stored inside of the cookie.
OK.
That is the difference.
And that's what we are going to figure out.
So we are making when we are making use of the cookies session library we say that the cookie is the
session the cookie contains all of the data related to the current session.
It contains the actual user ID.
So in our application when we want to figure out what the idea of the current user is we look into that
cookie we decode the value in there and the exact value inside that cookie is what we just saw inside
our browser or go on that record session thing.
This is the exact information right here that is stored inside of our cookie.
So that's with cookie session.
Now how does express session work.
So this is the one that we did not use.
This is the one that behaves slightly differently.
Express session works by storing a reference to a session inside the cookie a reference to a session.
So when you make use of express session it will store inside of the session or inside the cookie excuse
me an ID to a session.
So anytime that a request comes back around to express session express session takes the ID out of there.
It then looks up all of the relevant session data from what we refer to as a session store.
So in other words the cookie only contains this one very small individual ID and nothing else.
And then to access all the data associated with that particular cookie we store all the relevant data
inside of some other outside database or some remote store of data.
So I know that this might seem like a very small difference and I might not even be exactly really being
clear on what's going on here.
So one more diagram I want to show you to really clarify the difference.
So this is what happens with Express session.
The one that we're not using inside the cookie the cookie gets parsed and then we just see the data
session id of like 2:59 to figure out what the actual like user ideas or whatever other data we try
to store inside the data inside that cookie.
We would then go off to this session store right here.
We would look up this very particular session id of like 1 to 3 and that would then return us a little
object that contains all of the relevant data.
So putting this another way putting it out in like probably way more clear terms than I am right now
because again this is like crazy stuff.
The big difference between the two is that cookie session stores all the data directly in the cookie
express session stores all the data in some like remote server side data store.
And then whenever request comes in it takes the idea out of that session and then go goes and polls
all the relevant data out of the session store.
So just to further simplify this put a different way because I'm droning on now I know I'm sorry putting
a different way.
The big difference between these two is that with Express section session we are trying to store all
the data outside the cookie with cookies session.
We're stuffing everything into the cookie.
I guess that's as concise as I can make it.
I apologize if that's not clear.
Doing my best.
So why do we care about using one or the other.
That's the real takeaway.
Why are we using one or the other.
Well the big difference between the two is that with Express session we can store as much data as we
want to inside of that remote or that session store because that is some big bucket of data that we
can post on our server and we can stuff as much stuff in there as we want to with a cookie.
We are limited to around 4 kilobytes and that's all we have access to that's all the data we can stuff
on the cookie.
Now for our application all we really care about is the user ID right.
That's the sole thing we care about.
We don't care about anything else inside of our application we just care about the user's ID and nothing
else.
So we are definitely well below that forks in kilobyte size limit and so we don't really have to make
use of this external session store to get around that size limit because we are not storing a big old
bucket of data in there.
So that is the difference between cookie session and express session to further drill home the point
here.
If you look at the Express session documentation and you scroll down to like the very bottom is a section
down here that says sessions store implementation and right beneath that you will see compatible session
stores.
So if you are making use of express session it expects you to set up one of these session stores for
it to actually store all the session data all the relevant data.
And so by using cookie session we completely circumvent this requirement right here by using cookie
session and just stuffing everything directly in the cookie.
We don't have to set up this outside service which is undoubtedly just a pain in the rear.
So it really just saves us from having to go through this pain right here.
OK.
All right.
So I know that that topic was a little bit of a pain but there's just one last thing I want to show
you inside of our application and this is going to be a thing that if you feel a little bit kind of
queasy around cookies right now and what cookies are doing last year and talking about is kind of like
see our cookies being set in practice.
So again remember at this point this is all completely optional stuff.
You can always pause video and continue on.
So I want to walk through our authentication flow and I want to get some like visual look on our cookies
as they are being set by our server.
So inside my browser I'm going to open up the Google Developer tab and you can do that by doing view
developer view source or of course you can always right click and just inspect anywhere.
Then once I open this thing up I'm going to open up the network request tab.
So I've now got network request being recorded.
So again my goal here is to walk through the authentication flow and I want to look at that cookie and
see how it is being set by our server.
The first thing to do is I'm going to log out by accessing local host Colin 5000 slash API slash log
out and when I do so I can now click on the request that was just made.
This contains the response that we just got back from the server and in the headers section right here
you'll see a list of all the response headers.
So these are headers that were included with the request that got sent back to us.
One of the headers that is in here you will see is the set cookie header.
And so right here it says session is blah blah blah blah blah.
As a reminder whenever the cookie session middleware runs it always encrypts our cookie.
So we do not see the session in plain text right here.
This is the encrypted session but this contains everything having to do with our current session.
We can now go through the authentication flow and as we do we will see this cookie set cookie session
thing right here start to change.
So I'm now going to go to auth slash Google after I do that.
Now click on this red arrow.
Out request in on here I can now look at the response headers and you'll see that the session is now
significantly longer because now my session contains not only that odd URL now contains the actual user
ID.
So it literally just contains more information here now.
And that's why I see many more characters here.
Now of course I can also go to say Auth. or C API.
Slash current user when we do that we do not get back and your response header because on the API slash
current user route we are not modifying our Kuki in any way right.
We're not modifying the cookie we're not setting it.
We're not deleting it.
We are reading it.
We are definitely reading on the server.
But remember that the server or the client automatically includes a cookie with any request.
So we don't see anything here in this case around response headers around the cookie because the server
is not modifying anything.
If we scroll down a little bit however you'll find the request header section and inside of here you'll
find the header that includes our cookie automatically.
And this is where the browser is automatically including the cookie and sending it to our back and server.
And so here's the string right here.
This is the encrypted object or the encrypted string that essentially contains our user ID and says
hey we are a user.
So and So and So.
So clearly that is being communicated automatically by our browser to the back and server.
Now again we can log out doing API slash log out.
And when I do that again set cookie and yes there is a session here.
But if you were to decrypt this thing right here it would essentially say empty session like there's
no data left completely empty.
Nothing here.
So we no longer have a user ID.
In this case.
OK.
So that's pretty much it.
That's the three topics I want to go over.
We spoke about middleware.
We had a awkward discussion about cookie session versus express session.
Again I really just wanted to kind of communicate the difference between the two using cookie session
is far more straightforward.
So much easier to get started with.
And really for any reasonable application is going you serve you very well.
And then we also got to observe the cookies being automatically managed by our browser and by our express
server.
So that's pretty much it.
That's all I wanted to talk about here.
Let's now continue in the next section and continue working on our server so I'll see you in just a
second.