So we have this log and flow in place here.
It's not wired up yet. And even if it would be wired up,
we would as mentioned,
not really be able to see if a user is now really treated as
logged in since we have no logic on our website at the
moment to reflect that.
And that is what I want to change here for this,
for all incoming requests.
I want to check if that request is coming from a user that
is actually locked in,
and then we can use that information to, for example,
show a different navigation bar with more and different
options in the rendered website.
And we could also lock down access to certain pages based on
the authentication status, something we'll also do later.
So either way,
we want to look into the incoming request session to extract
information from it and see whether it's coming from an
authenticated user.
And we can do that with our own middleware.
Hence in the middlewares folder,
I'll add a new middleware file,
which will name authenticate or check
off JS.
That's that even better name.
And in here, I'll add a function, check off status,
which is a default middleware function.
So which gets a request or response and the,
this next function.
And then in here,
I in the end,
want to
get my
user ID
by accessing rec dot session dot UID.
Because remember when we
do call create user session or
after checking for email and password correctness,
then thanks to the function we wrote here.
We will add a UID field two to session,
and that will be stored on the server in that session data,
in our case, in the database,
because we're using the Mongo DB session store.
So now for every incoming request with help of this custom
middleware, I will look for this UID field.
And this then either is undefined. If a doesn't exist,
which means the user did not log in before,
or it is a value, some ID value, which only can be the case.
If the user did log in before otherwise it wouldn't have
been set.
So the offer here, I can check if not UID,
which means the user does not have one,
the user to which this session belongs.
So the user from which this request is coming,
and in this case, I want to return and not continue,
and I will return the result of calling next.
The result isn't too important,
important is that we call next so that the request can still
travel on because not being authenticated does not mean that
we want to crash the app or send you an error.
It just means that the there officer shouldn't execute.
That's why return here because in the coat they're off after
I will actually add a couple of response,
specific fields with help of resolute KOLs,
which we used before for the CSRF token to store the user ID
in there, but to also add an S off utility field,
which I set to true to indicate that the user with which we
are working now is authenticated.
And we can use this information in our views or our other
route handlers and middleware functions. Then for example,
and then their offer, I, again, call next.
But now I only do that if we made a POS, does if check,
which we only do, if the user has a user ID,
which means the user is authenticated,
then we can, of course,
export does check off status middleware function year,
and then registered this in app JS here where I'm already
importing a bunch of other middleware functions.
We can add the check off status middleware
by requiring
dot slash middlewares
slash
check off
like this.
And with it being required, we can use it.
Now, we want to use it after the
session middleware executed.
Otherwise we won't be able to access the session.
And it doesn't matter if we check for
to see as I've token first,
I will simply use my checkoff status middleware here after
the add CSRF token middleware.
So now we have this added here
now with debt,
since insight off that middleware,
we just worked on
I'm actually setting, wrestle.
Locals is off and UID. We can use that data in our reviews.
And for example, we can use it in our header.
Now in our header,
in this shared includes folder,
we don't really have any navigation items yet,
but what we can do in here is in this NAF bar,
we can actually add a unordered list because we'll have one
later anyways, with every navigation item,
being one list item in that list.
And there we can add I'll list item,
which actually has to log out button.
And that lists item here should only be added if the user is
authenticated,
otherwise it makes no sense to show a log out button.
So then here we can use EJS text to add if condition in the
template to check if locals is off.
If this is true and keep in mind, that's this field,
which I'm setting here in my custom middleware.
So I'm checking if this is true,
and then we have an opening curly brace,
and then this template part here will be rendered
and their offer.
I just closed this, but now it is will only be rendered.
If this here is true, that's how EJS works.
So now in the navigation,
we have some visual feedback telling us whether that worked
or not with that. If I reload,
I don't see log out anywhere in my navigation.
It's not styled,
but I don't see it anywhere because I haven't locked in yet.
But now with all that logic added, once we do log in,
we should be able to see it for this as a last step.
We just need to make sure that the log in function and the
off controller is actually wired up to the log in route to
which we send the forum.
Once it's submitted for dad in the auth routes JS file,
we should register a new route
a post route to slash login because
that's the kind of request
we're sending from inside the log in EJS file.
And here we want to target off controller dot and then we
need to expose that log-in function.
We added into auth controller.
So this function here,
which we added needs to be added down there in the export at
object.
Once it is added there in the routes file on the auth
controller, we can point at it.
Now we should be able to send post requests there and
trigger our authentication flow once we do so.
If we now reload and I try logging in here
with valid credentials,
I'm redirected to the starting page and I have to log out
button here.
And that proves that logging in works that our
authentication logic, which he was as sessions works,
otherwise,
we wouldn't see that button because this button is rendered
conditionally,
and it's only rendered if we are authenticated,
that's the logic we added here.