Now, before we now take a closer look
at cookies and sessions again,
I want to implement the logout functionality,
because at the moment that is not working
and to make it work,
we have to think about what should happen
if we click Logout.
Well, what happens at the moment
is that this logout post route here is reached
or it should be reached,
because if I have a look at my header
for this Logout button,
it's in a form because I want to send a POST request
because since we change something on the server
in the database,
it makes more sense to me to use a POST request.
And it is a POST request send to /logout.
Now to make sure that something happens
in this post logout route here, which already was prepared,
we in the end want to delete that authentication data
from the session because it's the existence of this data
that grants us access to the protected resources.
We check for isAuthenticated and/or the user here.
So if we cleared that data from the session,
the user, the visitor,
who's trying to access a certain page,
won't be able to do so anymore.
We could also delete the entire session object
from the database and therefore clear to cookie,
but you should think twice about
whether you want to do that or not,
because as mentioned before,
sessions can also be used for storing other data.
One of the most prominent examples
would be the shopping cart,
which you might want to store
even for unauthenticated users.
That's a behavior you know from Amazon and so on as well.
There you can add items to your shopping cart
without being authenticated.
So deleting the overall session is something you could do,
but you typically don't want to do that.
Instead, here in the logout route,
I will simply reach out to my session and set user to null.
And with that, I will effectively clear it.
Null is also a built-in value in JavaScript
that will be treated as a falsy
if you would see it in a if check.
So that will clear the user data from there.
And I will set the isAuthenticated key to false
because this user isn't authenticated anymore.
Alternatively, we could also set this to null
because this would also be treated as falsy,
but since it is a Boolean already,
I'll just set it to false.
And then I want to redirect the user
back to the starting page.
Now we could again, save the session as we did it here
when we first logged the user in
and only redirect once we know that saving worked,
but I only to do it like this here
because I wanted to redirect the user to a page
that relied on that session data being stored,
because I redirected to a page
that required that data to be there because it's a page
that required the user to be authenticated.
Here I'm redirecting to the starting page,
which doesn't care about
whether the user is authenticated or not,
and therefore here,
we can rely on the auto-saving mechanism,
which has built into the express session package
because we don't care
whether redirecting or saving finishes first,
since the redirected page doesn't rely on the saved data.
So therefore now with that, if we save this,
if we go back to the page, at the moment,
I can still visit The Admin Page,
but if I now click Logout,
I'm redirected to the starting page.
And if I now try to visit Admin,
I get the Not authenticated page again.
Now, if we have a look at the developer tools,
I still have my session cookie,
because again, I did not delete the session,
but we'll see a difference in the database.
If I query my sessions collection again,
then we see the session is still there,
but user is null and isAuthenticated is false.
And that is the key thing.
We still have our tickets, so to say,
but it's now saying, "You don't get access. Sorry."
This is what we did now,
and that's how we can add this logout functionality.