1
00:00:03,000 --> 00:00:04,967
We wrote this NavBar component

2
00:00:04,967 --> 00:00:08,115
that will be displayed at the top of every page.

3
00:00:08,681 --> 00:00:12,280
But we still need a way to fetch the "user" data,

4
00:00:12,280 --> 00:00:15,659
and check if the user is authenticated or not.

5
00:00:16,233 --> 00:00:18,361
At the beginning of this section

6
00:00:18,361 --> 00:00:20,823
we had a look at various API requests

7
00:00:20,823 --> 00:00:22,286
available with Strapi.

8
00:00:22,920 --> 00:00:25,071
And, if you remember, one of them

9
00:00:25,071 --> 00:00:27,417
allows us to fetch the user details.

10
00:00:27,983 --> 00:00:32,027
If we call "/users/me", passing a valid token,

11
00:00:32,027 --> 00:00:35,983
we get back a JSON object with the user data.

12
00:00:36,570 --> 00:00:38,214
So this is what we can use

13
00:00:38,214 --> 00:00:39,984
to get the user information.

14
00:00:40,547 --> 00:00:42,753
All we need to make this request

15
00:00:42,753 --> 00:00:46,269
is the JSON web token that was returned in a cookie

16
00:00:46,269 --> 00:00:48,130
after a successful sign in.

17
00:00:48,767 --> 00:00:50,903
However, the problem is that

18
00:00:50,903 --> 00:00:53,573
we cannot read that cookie directly

19
00:00:53,573 --> 00:00:56,319
from JavaScript code in the browser.

20
00:00:56,319 --> 00:00:59,522
Because we set the cookie to be "httpOnly"

21
00:00:59,522 --> 00:01:02,649
it's not visible to our client side code.

22
00:01:03,454 --> 00:01:05,810
The only way to read that cookie

23
00:01:05,810 --> 00:01:07,577
is from the server side.

24
00:01:07,577 --> 00:01:11,185
So what want to do is create another API handler,

25
00:01:11,185 --> 00:01:13,394
similar to this "login" route,

26
00:01:14,114 --> 00:01:16,002
but acting as a proxy for

27
00:01:16,002 --> 00:01:18,418
the Strapi "/users/me" resource.

28
00:01:18,993 --> 00:01:20,904
Let's call this route "user",

29
00:01:20,904 --> 00:01:23,407
since it will return the user details.

30
00:01:26,793 --> 00:01:29,153
This will be an API handler function,

31
00:01:29,153 --> 00:01:32,278
so let's start by returning an empty JSON object.

32
00:01:32,859 --> 00:01:35,908
And of course we need to export that function

33
00:01:35,908 --> 00:01:37,872
as the default module export.

34
00:01:38,439 --> 00:01:40,981
Now, the new thing we need to do here

35
00:01:40,981 --> 00:01:43,317
is read the cookie with the token.

36
00:01:43,885 --> 00:01:47,440
And we can find the cookies sent in the request

37
00:01:47,440 --> 00:01:49,709
in the "req.cookies" property.

38
00:01:50,284 --> 00:01:52,759
Let's see how we can test this code.

39
00:01:53,259 --> 00:01:56,263
Since the cookie is already set in the browser

40
00:01:56,263 --> 00:01:58,550
I'm going to call our new API route

41
00:01:58,550 --> 00:02:01,032
directly from this JavaScript console.

42
00:02:01,662 --> 00:02:04,364
We can do that by calling "fetch"

43
00:02:04,364 --> 00:02:07,065
and passing the "/api/user" path.

44
00:02:07,646 --> 00:02:10,934
This return a Promise, so let's call "then",

45
00:02:10,934 --> 00:02:13,623
take the response, or "r" for short,

46
00:02:13,623 --> 00:02:15,117
and return its JSON.

47
00:02:15,766 --> 00:02:17,602
Let's chain another "then"

48
00:02:17,602 --> 00:02:19,861
that will receive the JSON data,

49
00:02:19,861 --> 00:02:21,908
and pass it to "console.log".

50
00:02:22,549 --> 00:02:23,783
If we run this code,

51
00:02:23,783 --> 00:02:25,819
you can see that in the last line

52
00:02:25,819 --> 00:02:27,423
it logged an empty object,

53
00:02:28,046 --> 00:02:30,253
which is what we return in our response.

54
00:02:30,753 --> 00:02:33,468
But, more interestingly, in the server logs

55
00:02:33,468 --> 00:02:36,309
we can see the cookies sent with the request,

56
00:02:36,309 --> 00:02:38,581
and they contain the JSON web token.

57
00:02:39,207 --> 00:02:42,219
So now that we know how to read the cookies,

58
00:02:42,219 --> 00:02:45,573
we can extract the "jwt", from the "req.cookies".

59
00:02:46,573 --> 00:02:48,481
And at this point we can call

60
00:02:48,481 --> 00:02:50,586
the Strapi "/users/me" resource.

61
00:02:51,151 --> 00:02:52,995
This will be similar to what did

62
00:02:52,995 --> 00:02:54,320
in our "login" handler.

63
00:02:54,877 --> 00:02:57,291
First of all we need the "CMS_URL"

64
00:02:57,291 --> 00:02:59,704
that we can paste here at the top.

65
00:03:01,043 --> 00:03:04,402
And then we can call our usual "fetchJson" function,

66
00:03:04,402 --> 00:03:06,728
passing a string with the "CMS_URL",

67
00:03:07,609 --> 00:03:11,522
followed by the path, that is "/users/me".

68
00:03:12,022 --> 00:03:14,078
Next, we want to send the token,

69
00:03:14,078 --> 00:03:16,198
and that must be done in a header

70
00:03:16,198 --> 00:03:17,676
called "Authorization".

71
00:03:20,022 --> 00:03:22,140
As we've seen in the REST Client

72
00:03:22,140 --> 00:03:24,522
this value must start with "Bearer",

73
00:03:24,522 --> 00:03:26,374
followed by the "jwt" value.

74
00:03:27,006 --> 00:03:29,217
And that's it for the request.

75
00:03:29,217 --> 00:03:31,943
Now we can make this function "async"

76
00:03:31,943 --> 00:03:34,080
so we can await the response,

77
00:03:34,080 --> 00:03:36,511
that will return a "user" object.

78
00:03:37,232 --> 00:03:39,208
Ok. Now, let's think about

79
00:03:39,208 --> 00:03:42,704
what happens if the user is not authenticated.

80
00:03:43,280 --> 00:03:46,615
If the request doesn't include the "jwt" cookie,

81
00:03:46,615 --> 00:03:49,880
then there's no point in trying to call the CMS

82
00:03:49,880 --> 00:03:51,548
to get the user details.

83
00:03:52,186 --> 00:03:53,880
We might as well return

84
00:03:53,880 --> 00:03:56,236
an error response straight away,

85
00:03:56,236 --> 00:03:58,223
such as "401 Unauthorized".

86
00:03:58,870 --> 00:04:01,069
And let's not forget to "return" here,

87
00:04:01,069 --> 00:04:04,194
because we don't want to execute the rest of the code.

88
00:04:04,751 --> 00:04:08,366
Ok. We're almost done but by now we know that

89
00:04:08,366 --> 00:04:10,855
whenever we make an API request

90
00:04:12,217 --> 00:04:13,992
we also need to think about

91
00:04:13,992 --> 00:04:16,096
what to do if the request fails.

92
00:04:16,661 --> 00:04:19,071
In this case we could again return

93
00:04:19,071 --> 00:04:21,410
a "401 Unauthorized" status code.

94
00:04:21,410 --> 00:04:24,316
As usual, I'm not differentiating between

95
00:04:24,316 --> 00:04:26,655
the case where the request failed

96
00:04:26,655 --> 00:04:28,710
because the token was invalid

97
00:04:28,710 --> 00:04:30,198
and other cases where

98
00:04:30,198 --> 00:04:32,821
maybe there was just a network error.

99
00:04:32,821 --> 00:04:36,152
In a production application you should do that,

100
00:04:36,152 --> 00:04:38,987
but here let's keep the example simpler.

101
00:04:40,053 --> 00:04:41,524
Now, the final thing is

102
00:04:41,524 --> 00:04:44,209
what should we return in this JSON object,

103
00:04:44,209 --> 00:04:45,743
if everything goes well?

104
00:04:46,370 --> 00:04:48,793
We want to return some user details,

105
00:04:48,793 --> 00:04:51,350
but like we did in the login "handler"

106
00:04:51,918 --> 00:04:54,425
we could return only some properties.

107
00:04:55,117 --> 00:04:56,809
In fact it's a good idea

108
00:04:56,809 --> 00:04:59,699
to return exactly the same data structure

109
00:04:59,699 --> 00:05:01,320
as the other API route,

110
00:05:01,320 --> 00:05:03,999
because that will come in handy later.

111
00:05:04,711 --> 00:05:06,853
Now, let's test this handler again,

112
00:05:06,853 --> 00:05:09,362
which we can do from the browser console.

113
00:05:09,924 --> 00:05:12,500
Let's just run the same code as before,

114
00:05:12,500 --> 00:05:14,813
and this time we get back an object

115
00:05:14,813 --> 00:05:16,927
with "id" and "name" properties.

116
00:05:16,927 --> 00:05:18,314
So it's working fine.

117
00:05:19,013 --> 00:05:20,570
If we check the server logs,

118
00:05:20,570 --> 00:05:22,016
there's nothing new there.

119
00:05:22,572 --> 00:05:25,981
Now, let's test the case where there is no "token".

120
00:05:26,481 --> 00:05:28,934
To do that we can simply select this cookie

121
00:05:28,934 --> 00:05:29,733
and delete it,

122
00:05:30,291 --> 00:05:31,971
then go back to the console

123
00:05:31,971 --> 00:05:33,588
and execute "fetch" again.

124
00:05:34,191 --> 00:05:37,302
This time the GET request to "/api/user"

125
00:05:37,302 --> 00:05:39,713
failed with "401 Unauthorized",

126
00:05:39,713 --> 00:05:42,357
which is exactly what we expected.

127
00:05:43,013 --> 00:05:44,784
If we check the server output,

128
00:05:44,784 --> 00:05:47,499
again we're not logging anything in this case.

129
00:05:48,059 --> 00:05:49,277
But that's fine.

130
00:05:49,277 --> 00:05:52,778
I think our new "user" API route is now ready.

131
00:05:53,355 --> 00:05:55,788
It reads the cookie with the token

132
00:05:55,788 --> 00:05:58,794
and calls the CMS to get the user details.

133
00:05:58,794 --> 00:06:01,084
In the next video we'll continue

134
00:06:01,084 --> 00:06:02,873
by calling this API route

135
00:06:02,873 --> 00:06:04,734
from the NavBar component.