So at this point, we did now add user login.
We are checking that email and password provided by the user
to see whether we find that data in our database.
But right now, of course it still makes no difference
whether we logged in or not.
We can always reach this admin page,
which for this demo here,
I actually would like to protect
against unauthenticated access.
So how do we get there?
For this, it is really important to understand
that log in is not a feature you just add to your website
and all of a sudden it works the way you want
and all the pages you want to protect are protected.
Instead, adding user login is just one step
of three main steps for authentication
and it's the overall process, adding signup,
adding log in and then, in the third step,
using that login information to protect pages
that will allow you as a developer
to guard certain areas of your website
against unauthenticated access.
So it's not a feature you just drop into your website.
Instead, you as a developer
really have to write the code for the different steps
to make sure that certain areas are not accessible
by certain users.
And we completed the first two steps,
which are now the prerequisites for the major third step,
where we now wanna use the user data we have
and where we wanna use this login step
to finally lock down a certain part of our website
and still grant access to some users who did login.
But how do we lock down a certain part of our website?
Well, for this, we will need to track
the user authentication status, somehow.
Because to the web server, to our backend code,
by default, every incoming request looks quite similar.
Of course, it's coming from a different computer,
a different IP address
but those IP addresses are also dynamic.
For example, you don't always have to same IP address,
so we can't really use that for remembering
who's logged in and who's not.
And therefore in the end, every request looks similar
and by looking at a plain request like this,
we're not able to tell who should be allowed
to access a certain resource and who should not be allowed.
Instead we, as a developer,
will need to implement some kind
of ticketing system, you could say.
If you book a ticket for a flight,
then you get a ticket to your smartphone or via email
and the flight company, the airline,
actually of course also keeps an entry in their database
so that when you come with your ticket
to the airport and you show your ticket there,
you are granted access to the plane.
And of course, that does not just work like this for flights
and planes but basically for all kinds of events.
If you book a ticket for the cinema,
then you also get your ticket
and they also have a copy in their system
with which they could check
if people are showing faked tickets or anything like this.
And now it's the same for web servers.
As a developer, we will have to write code
where we generate some kind of ticket, you could say,
on the server, which we store on the server
in the database, for example.
And where we then also hand out a copy of the ticket
or the ID of the ticket to our user.
So to the browser, in this case,
for the user to store it and to show it to us
when he or she wants to access a protected resource.
That is what we will now need to implement.
So that in our server side code,
in the routes here for the admin route,
for this route here, we could then, for example,
add some code to check the user ticket
and see if the user, if the request who's arriving,
has a valid ticket,
which we also stored in the server side database.
And we only render this admin page
if a valid ticket was shown to us,
otherwise we rendered this 401 template
where we tell the user
that he or she is not authenticated.
That is the final step of authentication,
which we will now need to implement.
And the idea simply is that when a user logs in,
so when that login data is submitted
and then verified on the server,
we generate such a ticket and send that back to the user,
so that the browser of the user is able to store it
and then show it to us in future requests
where access to protected pages is requested.
And here's how this process will look like in detail.
We're going to leverage a feature called sessions,
which is not a feature exclusively available
for authentication purposes,
as I will show you in this session
but which we typically do leverage
for authentication purposes.
Because sessions will be these tickets
that we generate on the server.
But here's how the overall process will look like.
We got the various involved parties, the client,
so the user using a browser, our server
and then probably some database
or some other data storage like us storing data
in some files.
So some data storage which we access on the backend
and all these processes are talking to each other
as we learned it throughout this course.
Now a user wants to log into our website
and then in the future, access protected resources.
For this, the user sends us the login credentials
and on the server, we then validate those credentials.
These are the steps we implemented
in the last lectures already.
We are able to get the login data and verify it
but now we'll reach the new steps
which we have yet to implement.
Once we've validated and confirmed the user credentials
on the server, we will generate such a ticket,
a so-called session, which is just a piece of data,
a record or a document for our database in the end,
which we will insert in the database.
And we don't need a database necessarily,
it's just a piece of data
which we need to store somewhere.
We could even store it in memory on the server
but there, it would, for example, be lost
if the server restarts.
We could store it in a file or as shown here, in a database.
So it's a record, a document,
with only a few pieces of relatively trivial data
that will be stored in the database.
Most importantly, such a session record or document
will have a unique ID.
Every session will have its own unique ID
and whilst we will be able to use this session feature
for all kinds of things,
we can also use it to store information that a certain user
should be granted access to certain resources.
Because that's the important thing.
Every session will be unique per user,
so every visitor of our website
will receive his or her own session.
And actually, that session can and in reality,
often will already be created
before the user even logged in
but before the user logged in,
we will simply store the information
that this user hasn't logged in yet in the session.
But then we will still have a session for this user
and we can map a session to a user
because the server will send back the session ID
to the client, so to the user.
And there, it will be stored in a so-called cookie.
(paper crinkles)
So that cookie will be sent back to the client
and the client will then automatically store
and manage this cookie,
so the browser will do this for us.
And you might've heard about cookies as well.
We all know them from those friendly
and super convenient banners,
which we see on a lot of websites these days.
Cookies can be used for bad or annoying things
like tracking and advertisement
but we can also use them for authentication,
simply to store a session ID in the browser
so that we have the session on the server side in a database
and then the unique ID of the session
and only that, also in the browser.
And why do we need that ID in the browser?
Because once the browser knows
the ID of a session that's stored on the server,
that session ID can be sent with subsequent requests
to the server and therefore then the server knows
that this request is coming from the client
with a certain session ID.
The server is then able to look for this session ID
in the database and then extract any data
that might've been stored for this specific client
in that session.
And there can be all kinds of data.
We could store a shopping cart in such a session.
And as I mentioned,
you don't even have to be authenticated
for this feature to exist
because we can create such a session with a unique ID
and send that ID back to a client,
no matter if that client logged in or not.
But that session can also contain a flag or a piece of data
that says this client with this unique ID is authenticated.
And that's then what we can look for to grant access
to protected resources.
That's the big picture.
Now, before we implement all of that
and go through this process step-by-step,
let's take another closer look at sessions and cookies,
which are two key concepts in web development.
And here it's important to understand
and to keep in mind that sessions
are a server side construct,
which are stored on the server side,
for example, in a database
and cookies are stored on the client side,
and there are different kinds of cookies.
As I mentioned, also for tracking
or advertisement but session cookies,
so that store the ID of a session,
are one of the more useful use cases for cookies,
one of the less annoying use cases, so to say,
because these session cookies are crucial
for mapping a client to a certain session on the database.
And unlike the IP address of a client, for example,
which often is dynamic and changes on a daily basis
or even more frequently, the session cookie
is a long lived cookie which doesn't change randomly.
So the session ID the server sent back to a client
does not change all the time, instead it's fixed
and that cookie can be stored in the browser for days,
weeks, months, or even years.
But it is worth knowing that sessions and cookies
are not exclusively used for authentication.
I mentioned that cookies can be used for tracking and so on
and I will show you another use case for sessions
in this course section,
because sessions, as I emphasized before
and as I wanna emphasize again,
are not authentication-exclusive.
Instead, unauthenticated users
can and will also receive sessions
since you can store all kinds of data in them
and the flag that a certain user is authenticated
is just one possible piece of data you can store in there.
So it really comes down to which data
you store in a session
and you can then do all kinds of things with that data,
as you will see in this section.
And then for cookies, well there,
we got other use cases as well
but a lot of them are annoying
and therefore, we'll focus on the session cookies,
which are very useful and absolutely required
in this course section here.