We wrote this NavBar component
that will be displayed at the top of every page.
But we still need a way to fetch the "user" data,
and check if the user is authenticated or not.
At the beginning of this section
we had a look at various API requests
available with Strapi.
And, if you remember, one of them
allows us to fetch the user details.
If we call "/users/me", passing a valid token,
we get back a JSON object with the user data.
So this is what we can use
to get the user information.
All we need to make this request
is the JSON web token that was returned in a cookie
after a successful sign in.
However, the problem is that
we cannot read that cookie directly
from JavaScript code in the browser.
Because we set the cookie to be "httpOnly"
it's not visible to our client side code.
The only way to read that cookie
is from the server side.
So what want to do is create another API handler,
similar to this "login" route,
but acting as a proxy for
the Strapi "/users/me" resource.
Let's call this route "user",
since it will return the user details.
This will be an API handler function,
so let's start by returning an empty JSON object.
And of course we need to export that function
as the default module export.
Now, the new thing we need to do here
is read the cookie with the token.
And we can find the cookies sent in the request
in the "req.cookies" property.
Let's see how we can test this code.
Since the cookie is already set in the browser
I'm going to call our new API route
directly from this JavaScript console.
We can do that by calling "fetch"
and passing the "/api/user" path.
This return a Promise, so let's call "then",
take the response, or "r" for short,
and return its JSON.
Let's chain another "then"
that will receive the JSON data,
and pass it to "console.log".
If we run this code,
you can see that in the last line
it logged an empty object,
which is what we return in our response.
But, more interestingly, in the server logs
we can see the cookies sent with the request,
and they contain the JSON web token.
So now that we know how to read the cookies,
we can extract the "jwt", from the "req.cookies".
And at this point we can call
the Strapi "/users/me" resource.
This will be similar to what did
in our "login" handler.
First of all we need the "CMS_URL"
that we can paste here at the top.
And then we can call our usual "fetchJson" function,
passing a string with the "CMS_URL",
followed by the path, that is "/users/me".
Next, we want to send the token,
and that must be done in a header
called "Authorization".
As we've seen in the REST Client
this value must start with "Bearer",
followed by the "jwt" value.
And that's it for the request.
Now we can make this function "async"
so we can await the response,
that will return a "user" object.
Ok. Now, let's think about
what happens if the user is not authenticated.
If the request doesn't include the "jwt" cookie,
then there's no point in trying to call the CMS
to get the user details.
We might as well return
an error response straight away,
such as "401 Unauthorized".
And let's not forget to "return" here,
because we don't want to execute the rest of the code.
Ok. We're almost done but by now we know that
whenever we make an API request
we also need to think about
what to do if the request fails.
In this case we could again return
a "401 Unauthorized" status code.
As usual, I'm not differentiating between
the case where the request failed
because the token was invalid
and other cases where
maybe there was just a network error.
In a production application you should do that,
but here let's keep the example simpler.
Now, the final thing is
what should we return in this JSON object,
if everything goes well?
We want to return some user details,
but like we did in the login "handler"
we could return only some properties.
In fact it's a good idea
to return exactly the same data structure
as the other API route,
because that will come in handy later.
Now, let's test this handler again,
which we can do from the browser console.
Let's just run the same code as before,
and this time we get back an object
with "id" and "name" properties.
So it's working fine.
If we check the server logs,
there's nothing new there.
Now, let's test the case where there is no "token".
To do that we can simply select this cookie
and delete it,
then go back to the console
and execute "fetch" again.
This time the GET request to "/api/user"
failed with "401 Unauthorized",
which is exactly what we expected.
If we check the server output,
again we're not logging anything in this case.
But that's fine.
I think our new "user" API route is now ready.
It reads the cookie with the token
and calls the CMS to get the user details.
In the next video we'll continue
by calling this API route
from the NavBar component.