At this stage in the development of the SignInPage,
we can submit the login details
and we get a response from the API
that includes a JSON web token.
The next step would be to save that token somewhere
so we can send it back to the server
whenever we make another API request,
to prove that we are authenticated.
But where exactly should we save that token?
We have pretty much two options.
The first one would be to save it into Local Storage,
as we did in the Blog example
with the Dark Mode setting.
The downside to using Local Storage is that
it's not the most secure place to store
sensitive data, like authentication details.
Because any JavaScript code that runs on the page
can read from Local Storage.
So if there is some vulnerability in your code
that allows a malicious user
to inject code into your page,
they could be able to steal the token.
A more secure approach is to use cookies
to remember any sensitive data.
Cookies are set by the server,
and you can also set a cookie as "httpOnly"
which means it can only be read by the server,
and not by JavaScript code running in the browser.
So in this example we'll use cookies,
because it's a better choice
from a security point of view.
However, because a cookie can only be set by a server
this means we'll need to write an API route.
We'll have to write an API handler
and inside that code we can set the cookie,
returned as a header in the API response.
This also means that, in the SignInPage,
we'll need to call the API route,
rather than calling the CMS directly.
We'll basically take the approach
that we labelled as 2b
when we discussed all the possible ways
to fetch data in a Next.js app.
So, let's start by creating an API route,
that must be in a folder called "api" inside "pages".
Here let's create a route called "login".
This will be a "handler" function
that takes a request and a response.
Just as a starting point,
we can return a 200 OK response
with an empty JSON object.
And we also need to export
the handler function as the default.
By the way, this function doesn't have
to be called "handler".
We can name it however we like.
I usually call them "handleSomething",
like in this case "handleLogin".
Now, let's try calling that API route,
using the REST Client.
I'll add a new request here.
Let's make a GET request
to "localhost" on port "3000",
which means the Next.js server, not the Strapi one.
And the path is "/api/login".
Let's send this request,
and as expected we get a successful response
with an empty JSON object in the body.
But we should really make a POST request
like in the Strapi "auth" request, not a GET,
because we need to send some data to the server.
How can we handle a POST request
in a Next.js API route?
We can use the "req" parameter
passed to the handler function.
"req" is an instance of an IncomingMessage object
from the Node.js "http" module.
You can look at these links if you want to see
all the properties and methods available
on the request and also response objects.
But the "req" has a "method" property,
that we can use to check if it's a GET or POST.
Let's see how to use that in our code.
If we only want to accept POST requests
we can check if the "req.method" is not POST
and in that case we can set the "res.status" to 405
which means "Method Not Allowed".
And then we can call "end()"
to send the response without a body.
Since we want to stop at this point
we need to make sure to "return" here,
otherwise the normal execution flow
will continue and run the rest of the code as well.
Ok. Let's see how our API route works now.
If we send a GET request
the response is "405 Method Not Allowed",
which is what we wanted.
Now, let's make a POST request instead.
In this case we also want to send a JSON body,
just like when calling the CMS.
But, since we're now creating our own API
we could change this "identifier"
to be simply "email", which is more intuitive.
If we send this POST request,
we get a "200 OK",
because POST is a method we allow.
Now, the question is:
how can we access the data sent in the request body?
I'll log it so you can see it,
but the request object has a "body" property
that will contain that data,
Let's try it out, keeping an eye on the server logs.
If we re-send the POST request,
we can see in the logs that
it's an object containing "email" and "password".
And note that it's a JavaScript object,
so the original JSON string has
automatically been parsed.
So, this is how we can handle a POST request
in a Next.js API route.
We can first check the request "method",
and then get the request data
from the "req.body" property.
Let's stop here for this video,
but we'll continue in the next one
by calling the CMS API from this handler.