So let's start on the front end.
And let's start utilizing the answer to the question
whether a user is authenticated or not there.
For example, I wanna make sure that the options
in the header change based
on whether we are authenticated or not.
And again, Next.js makes that pretty easy for us.
It is worth noting that after we locked in successfully,
Next.js added a cookie.
We can see this in the browser DevTools.
If we go to application,
cookies and select our domain.
Here we see some cookies that were set
and these are cookies which are generated
and managed by Next.js.
For example this session token
is this Jason web token in the end.
That was set automatically by Next.js
when we logged in successfully.
And it will also use that token automatically for us,
when we try to change what we see on the screen,
or when we try to send requests to protected resources.
For example we can get the answer
to whether the user is locked in or not,
by finding out whether it's such a valid token exists.
And we could come up with some code
that allows us to do that manually though
that code would involve that we need
to send that cookie to the server
and let the server decide whether it's valid or not.
And hence, it's good that we don't have to do that.
Instead if you wanna find out,
if the user using this page
at the moment is authenticated or not,
Next.js gives us a convenient way of doing that.
Let's say in our components,
in the main navigation component,
here I wanna show profile only
if the user is authenticated.
Since we use Next off,
all we have to do for that is we have to import something
from Next off client,
and that's something now is to use session hook
which we can use an any functional React component.
Here we cannot call use session and use session
will return an array with exactly two elements.
It is an array where the first element
is the session object describing the act of session,
and the second element is loading
which tells us wherever Next.js
is currently still figuring out
whether we are logged in or not.
And then for the moment I'll just lock both all log loading
and I will log session.
If we do that and save this,
and go back to the browser,
to the console and reload,
we see true and undefined and true
and some object and false in some object.
The first log is always the loading state.
So you'll see, initially we're loading,
we are finding out whether the user is authenticated or not.
And hence, we got no session object yet,
then at some point we're still loading
but we actually do have that object yet,
and hence then loading is false
and we have that object still.
And in that session object,
we got that user data which we encoded into our token.
And we got some expiration date
which tells us when that session will expire automatically.
Though it is worth noting
that this session will be prolonged automatically,
if the user is active.
So now that we know what's in there,
what we can do is we can change what we see based
on these two pieces of information.
And we can make sure that the profile link is only showing
up if we have of a session.
So note if we're still finding it out,
and also note if we found it out but the answer is no.
Only if we have a session
then we showed this information in our header.
So if I save this and reload,
you'll see that profile flashes briefly
because it's only loaded after a very short time duration.
Once we found out that we do have a session to be precise.
Now that flashing could be unpleasant here,
and I'll come back to how we can optimize all
of that later in this section.
But that generally is how we can find out
whether we are authenticated or not.
Now we can utilize this to then
for example, only show the log in link
if we don't have a session.
Only if we don't have a session,
we wanna show the log in link.
I actually also don't wanna show it
whilst we're still loading though.
So I wanna show it only if we don't have a session
and we're not loading.
So for not loading,
and we then know that we have no session,
then I wanna show the log in link.
For the log out button,
I only wanna show that if we do have a session
because logging out only makes sense
if we are logged in.
With that out of the way,
you'll see the log in link is now gone.
Now I am still on the log in page
because I can still visit that page.
I'll show how we can prevent this later as well,
but we now at least know how we can control
what we see on the user interface.
And that is an important first step.
Now, before we dive deeper into route protection
and how we can control which pages can be visited,
and how we can optimize all of that,
let's first of all, explore how we can log out
so that we can also go back to log out state.