So now, we learned how we can use sessions
for really enforcing authentication.
And that's the key thing
of the overall authentication process.
Now, this is how we can implement secure authentication.
And the login functionality is really
just one step in the overall process,
which, in the end, has to goal of establishing a session.
With that, you are authenticated data in it
once the login succeeded.
Now, before we continue with more information
about authentication and so on,
I wanna come back to Session and Cookies.
And I, first of all, wanna have a closer look at Cookies,
and make sure that we understand what a Cookie really is.
On this slide here, I mentioned that a Cookie is,
in the end, generated and sent back to the Client,
so to the Browser where it is then stored by the browser.
And we could validate that by having a look
at this applications area in the dev tools.
There, we indeed see that cookie.
But how is the cookie actually sent back with a response?
Where in the response can we see it?
Now to understand how that cookie is actually transmitted,
what I want to do here is I'll go to this new incognito tab
where I don't have a cookie yet.
And you can simply open a new browser or tab
to have to same situation.
So I don't have a cookie here yet.
And I then we'll go to the network tab there,
go to the login page, clear that.
And now I want to log in here.
And for this I'll use my well-known credentials
because even though it's a new tab,
this user, of course, still will be able to log in here
because it's the same users stored in the same database,
and we're talking to the same server.
And if I click log in here,
we see a bunch of requests being sent here.
And now if we inspect those requests here,
like this log in request here,
this post requests, specifically.
If we have a look at the Response Headers there,
what we'll see is that there is a Set-Cookie header.
A cookie is not data that's part of the response body
or anything like that.
Keep in mind, we worked with the response body
when we sent Ajax requests, for example.
There, we parsed the body off the response
we received after sending a request.
The cookie is not part of this body.
It's not encoded in JSON or any other format.
Instead, a cookie is sent back by the server
by setting this Set-Cookie metadata on the response.
This is a special metadata key,
which is identified by the browser,
which is the thing that we'll look at all these headers.
And then the value of the Set-Cookie key,
that is the actual cookie data and configuration
that will be set.
And here, the first thing we see
is the identifier of the cookie in the browser,
and then the value that should be stored for the cookie.
And that's what we see in the application tab as well.
Here, we got the cookie name, the identifier,
and then the value.
This is this long cryptic string here, also down there.
And that is what we have after the equal sign here
when this cookie is set.
And then after the semicolon,
various options are set for the cookie.
Like HttpOnly, and there are other options as well,
which in the end configure how long this cookie lives.
And if it must be sent through a secure connection,
if it can be edited through JavaScript.
An HttpOnly cookie, for example,
can't be edited through JavaScript, and so on.
This is how a cookie is set.
And you don't have to write this header,
this response metadata on your own.
Instead, you typically use packages for this.
Like express-session when you change that session
and there for a session was created,
and that cookie must be set.
If you want to manage other cookies
that are not related to sessions,
then when working with node and express,
you can use packages like cookie-parser,
which also allow you to work with cookies on a higher level,
so that you don't have to set
the cookie metadata on your own,
but that instead you can still just interact with the cookie
and metadata will then be set
automatically for you by that package.
But this is how a cookie is, in the end,
sent to the client, to the browser.
And the browser then automatically stores it for you.
So there's nothing you have to do about that.
And then for subsequent requests,
like us visiting the admin page here,
the cookie is not part of the response.
If you have a look at the Response Headers,
because we already do have that cookie here.
The cookie doesn't need to be set again,
because nothing about the cookie
or the session changed here.
Then in the Request Headers though,
we see that this cookie is sent along
with the request here.
Here, we got a Cookie header.
So not Set-Cookie as before
when we got the response where the cookies should be set,
but now it's part of the Request Headers.
And in the Request Headers, the browser by default
sends along all cookies that belong to the URL,
to which the request is sent.
And that's exactly what we need here
because the browser needs to send along
this session cookie with that request to the admin page,
because on the server, that cookie will be evaluated.
The session ID will be extracted
automatically by the package, the express-session package.
And then this session can be retrieved
from the database there.
And the server is able to find out wherever the visitor
who's sending this cookie should be granted access
to a certain page or not.
So this cookie, which has sent along
with this session ID inside of it,
is our real entry ticket, or at least it's our ticket
to a session that's stored in a database on the server.
And then it depends on the data being stored
in that session.
Whether a user with that cookie
will be granted access or not.
This is how that works.
So that was a lot of talking about cookies.
And the good thing is that you don't have to
actively do anything related to them,
but as a web developer, you should always understand
how things are working behind the scenes.
And there for, I did want to explain this to you as well.