1
00:00:03,000 --> 00:00:05,942
At this stage in the development of the SignInPage,

2
00:00:06,442 --> 00:00:08,771
we can submit the login details

3
00:00:08,771 --> 00:00:11,324
and we get a response from the API

4
00:00:11,324 --> 00:00:13,652
that includes a JSON web token.

5
00:00:13,652 --> 00:00:17,482
The next step would be to save that token somewhere

6
00:00:17,482 --> 00:00:20,186
so we can send it back to the server

7
00:00:20,186 --> 00:00:22,964
whenever we make another API request,

8
00:00:22,964 --> 00:00:25,593
to prove that we are authenticated.

9
00:00:26,543 --> 00:00:29,810
But where exactly should we save that token?

10
00:00:29,810 --> 00:00:32,185
We have pretty much two options.

11
00:00:32,759 --> 00:00:36,733
The first one would be to save it into Local Storage,

12
00:00:36,733 --> 00:00:38,907
as we did in the Blog example

13
00:00:38,907 --> 00:00:40,931
with the Dark Mode setting.

14
00:00:40,931 --> 00:00:44,154
The downside to using Local Storage is that

15
00:00:44,154 --> 00:00:47,078
it's not the most secure place to store

16
00:00:47,078 --> 00:00:50,376
sensitive data, like authentication details.

17
00:00:50,376 --> 00:00:54,050
Because any JavaScript code that runs on the page

18
00:00:54,050 --> 00:00:56,149
can read from Local Storage.

19
00:00:56,149 --> 00:00:59,597
So if there is some vulnerability in your code

20
00:00:59,597 --> 00:01:01,696
that allows a malicious user

21
00:01:01,696 --> 00:01:03,945
to inject code into your page,

22
00:01:03,945 --> 00:01:06,794
they could be able to steal the token.

23
00:01:08,118 --> 00:01:10,923
A more secure approach is to use cookies

24
00:01:10,923 --> 00:01:13,096
to remember any sensitive data.

25
00:01:13,667 --> 00:01:15,711
Cookies are set by the server,

26
00:01:15,711 --> 00:01:18,642
and you can also set a cookie as "httpOnly"

27
00:01:18,642 --> 00:01:21,777
which means it can only be read by the server,

28
00:01:21,777 --> 00:01:25,184
and not by JavaScript code running in the browser.

29
00:01:25,184 --> 00:01:27,706
So in this example we'll use cookies,

30
00:01:27,706 --> 00:01:29,614
because it's a better choice

31
00:01:29,614 --> 00:01:31,659
from a security point of view.

32
00:01:32,567 --> 00:01:36,182
However, because a cookie can only be set by a server

33
00:01:36,182 --> 00:01:39,183
this means we'll need to write an API route.

34
00:01:39,751 --> 00:01:42,356
We'll have to write an API handler

35
00:01:42,356 --> 00:01:45,649
and inside that code we can set the cookie,

36
00:01:45,649 --> 00:01:48,789
returned as a header in the API response.

37
00:01:49,442 --> 00:01:52,235
This also means that, in the SignInPage,

38
00:01:52,235 --> 00:01:54,539
we'll need to call the API route,

39
00:01:54,539 --> 00:01:57,123
rather than calling the CMS directly.

40
00:01:57,123 --> 00:01:59,427
We'll basically take the approach

41
00:01:59,427 --> 00:02:00,963
that we labelled as 2b

42
00:02:00,963 --> 00:02:03,686
when we discussed all the possible ways

43
00:02:03,686 --> 00:02:05,851
to fetch data in a Next.js app.

44
00:02:06,769 --> 00:02:09,907
So, let's start by creating an API route,

45
00:02:09,907 --> 00:02:13,962
that must be in a folder called "api" inside "pages".

46
00:02:14,538 --> 00:02:17,030
Here let's create a route called "login".

47
00:02:18,804 --> 00:02:20,775
This will be a "handler" function

48
00:02:20,775 --> 00:02:22,924
that takes a request and a response.

49
00:02:24,537 --> 00:02:26,447
Just as a starting point,

50
00:02:26,447 --> 00:02:28,815
we can return a 200 OK response

51
00:02:28,815 --> 00:02:30,802
with an empty JSON object.

52
00:02:31,454 --> 00:02:33,124
And we also need to export

53
00:02:33,124 --> 00:02:35,435
the handler function as the default.

54
00:02:35,999 --> 00:02:38,047
By the way, this function doesn't have

55
00:02:38,047 --> 00:02:39,286
to be called "handler".

56
00:02:39,286 --> 00:02:40,956
We can name it however we like.

57
00:02:41,563 --> 00:02:44,158
I usually call them "handleSomething",

58
00:02:44,158 --> 00:02:46,342
like in this case "handleLogin".

59
00:02:46,910 --> 00:02:49,680
Now, let's try calling that API route,

60
00:02:49,680 --> 00:02:51,284
using the REST Client.

61
00:02:51,856 --> 00:02:53,328
I'll add a new request here.

62
00:02:54,222 --> 00:02:56,224
Let's make a GET request

63
00:02:56,224 --> 00:02:58,726
to "localhost" on port "3000",

64
00:02:58,726 --> 00:03:02,980
which means the Next.js server, not the Strapi one.

65
00:03:03,646 --> 00:03:06,973
And the path is "/api/login".

66
00:03:07,473 --> 00:03:08,945
Let's send this request,

67
00:03:09,539 --> 00:03:12,231
and as expected we get a successful response

68
00:03:12,731 --> 00:03:14,655
with an empty JSON object in the body.

69
00:03:15,298 --> 00:03:18,179
But we should really make a POST request

70
00:03:18,179 --> 00:03:21,421
like in the Strapi "auth" request, not a GET,

71
00:03:21,421 --> 00:03:24,879
because we need to send some data to the server.

72
00:03:25,524 --> 00:03:28,331
How can we handle a POST request

73
00:03:28,331 --> 00:03:30,350
in a Next.js API route?

74
00:03:30,937 --> 00:03:33,080
We can use the "req" parameter

75
00:03:33,080 --> 00:03:35,294
passed to the handler function.

76
00:03:35,294 --> 00:03:38,793
"req" is an instance of an IncomingMessage object

77
00:03:38,793 --> 00:03:41,007
from the Node.js "http" module.

78
00:03:41,007 --> 00:03:44,292
You can look at these links if you want to see

79
00:03:44,292 --> 00:03:47,149
all the properties and methods available

80
00:03:47,149 --> 00:03:50,077
on the request and also response objects.

81
00:03:51,006 --> 00:03:53,871
But the "req" has a "method" property,

82
00:03:53,871 --> 00:03:57,414
that we can use to check if it's a GET or POST.

83
00:03:57,990 --> 00:04:00,129
Let's see how to use that in our code.

84
00:04:02,022 --> 00:04:05,359
If we only want to accept POST requests

85
00:04:05,359 --> 00:04:09,123
we can check if the "req.method" is not POST

86
00:04:10,423 --> 00:04:14,513
and in that case we can set the "res.status" to 405

87
00:04:14,513 --> 00:04:17,160
which means "Method Not Allowed".

88
00:04:17,740 --> 00:04:19,555
And then we can call "end()"

89
00:04:19,555 --> 00:04:21,887
to send the response without a body.

90
00:04:22,452 --> 00:04:24,604
Since we want to stop at this point

91
00:04:24,604 --> 00:04:26,940
we need to make sure to "return" here,

92
00:04:27,501 --> 00:04:29,855
otherwise the normal execution flow

93
00:04:29,855 --> 00:04:33,283
will continue and run the rest of the code as well.

94
00:04:33,850 --> 00:04:37,394
Ok. Let's see how our API route works now.

95
00:04:37,894 --> 00:04:39,669
If we send a GET request

96
00:04:39,669 --> 00:04:42,701
the response is "405 Method Not Allowed",

97
00:04:43,274 --> 00:04:44,810
which is what we wanted.

98
00:04:44,810 --> 00:04:47,306
Now, let's make a POST request instead.

99
00:04:47,869 --> 00:04:51,013
In this case we also want to send a JSON body,

100
00:04:51,013 --> 00:04:53,132
just like when calling the CMS.

101
00:04:53,700 --> 00:04:56,577
But, since we're now creating our own API

102
00:04:56,577 --> 00:04:58,891
we could change this "identifier"

103
00:04:58,891 --> 00:05:02,118
to be simply "email", which is more intuitive.

104
00:05:02,758 --> 00:05:05,021
If we send this POST request,

105
00:05:05,021 --> 00:05:06,425
we get a "200 OK",

106
00:05:07,003 --> 00:05:09,410
because POST is a method we allow.

107
00:05:09,910 --> 00:05:11,385
Now, the question is:

108
00:05:11,385 --> 00:05:15,037
how can we access the data sent in the request body?

109
00:05:15,607 --> 00:05:17,671
I'll log it so you can see it,

110
00:05:17,671 --> 00:05:20,697
but the request object has a "body" property

111
00:05:20,697 --> 00:05:22,623
that will contain that data,

112
00:05:23,260 --> 00:05:26,138
Let's try it out, keeping an eye on the server logs.

113
00:05:26,638 --> 00:05:28,711
If we re-send the POST request,

114
00:05:29,971 --> 00:05:31,930
we can see in the logs that

115
00:05:31,930 --> 00:05:35,485
it's an object containing "email" and "password".

116
00:05:35,485 --> 00:05:38,315
And note that it's a JavaScript object,

117
00:05:38,315 --> 00:05:40,564
so the original JSON string has

118
00:05:40,564 --> 00:05:42,450
automatically been parsed.

119
00:05:43,240 --> 00:05:47,039
So, this is how we can handle a POST request

120
00:05:47,039 --> 00:05:49,024
in a Next.js API route.

121
00:05:49,024 --> 00:05:52,477
We can first check the request "method",

122
00:05:53,149 --> 00:05:55,137
and then get the request data

123
00:05:55,137 --> 00:05:57,125
from the "req.body" property.

124
00:05:57,693 --> 00:05:59,780
Let's stop here for this video,

125
00:05:59,780 --> 00:06:02,068
but we'll continue in the next one

126
00:06:02,068 --> 00:06:04,828
by calling the CMS API from this handler.