WEBVTT

1
00:00:01.580 --> 00:00:06.480
So, I'll start by adding validation here to the added route as well and for that I'll

2
00:00:06.480 --> 00:00:13.480
just highlight it and say also add validation here and I hope that GitHub Copilot takes

3
00:00:13.480 --> 00:00:19.880
the other surrounding code into account and hence updates the code appropriately and that

4
00:00:19.880 --> 00:00:20.580
looks good to me.

5
00:00:21.460 --> 00:00:26.000
It's essentially the same checks as before when we created an event.

6
00:00:26.400 --> 00:00:32.680
So that looks good and therefore as a next step we can move on and protect some of our

7
00:00:32.680 --> 00:00:33.460
event routes.

8
00:00:34.880 --> 00:00:39.220
Make sure that some of these routes can only be visited by authenticated users.

9
00:00:40.600 --> 00:00:46.840
Now keep in mind for that we have this util folder with the auth.js file where we have

10
00:00:46.840 --> 00:00:54.020
the verifyToken function and this function can be used to find out whether an incoming

11
00:00:54.180 --> 00:00:59.620
token, a token that has been attached to an incoming request is valid or not.

12
00:01:00.820 --> 00:01:09.040
Now actually we should also have another utility function here and actually it is the function

13
00:01:09.040 --> 00:01:13.300
GitHub Copilot is suggesting to me here which is pretty nice.

14
00:01:15.120 --> 00:01:18.080
So yeah, I want to have this function here really.

15
00:01:19.760 --> 00:01:27.060
VerifyUtility function which receives an incoming request and which parses the token

16
00:01:27.060 --> 00:01:34.140
from the request headers there specifically from an authorization header.

17
00:01:34.929 --> 00:01:40.900
It extracts the token from that header like this because the header will actually be something

18
00:01:40.900 --> 00:01:42.240
like bearer and then the token.

19
00:01:42.400 --> 00:01:46.020
That's just a convention of adding the token to HTTP requests.

20
00:01:48.140 --> 00:01:54.180
So this will just give us the token and then it uses verifyToken, this function here, which

21
00:01:54.180 --> 00:01:58.220
we therefore technically wouldn't even need to export since we're using it in the same

22
00:01:58.220 --> 00:01:59.800
file but it doesn't matter.

23
00:02:00.060 --> 00:02:06.380
So we're using this function to decode and in the same step also verify the token because

24
00:02:06.380 --> 00:02:12.020
this step here will fail if the token is invalid.

25
00:02:12.380 --> 00:02:15.560
Verify will throw an error if it's an invalid token.

26
00:02:17.300 --> 00:02:26.480
So we either return an error response here or we store the decoded token, the content

27
00:02:26.480 --> 00:02:33.580
of the token therefore, which is that user data which we encode here, the ID and the

28
00:02:33.580 --> 00:02:33.780
email.

29
00:02:33.960 --> 00:02:39.500
That's the data we encode in the token and that's what we store in the request under

30
00:02:39.500 --> 00:02:40.360
a user object.

31
00:02:41.580 --> 00:02:46.480
And then next here is just a function that ensures that the next so-called middleware

32
00:02:46.420 --> 00:02:51.880
in line, the next function that should handle the incoming request becomes active.

33
00:02:53.780 --> 00:02:57.760
Otherwise an error is thrown or an error response is sent back.

34
00:02:59.540 --> 00:03:05.160
So this authenticate function here can now be used as a so-called middleware before other

35
00:03:05.160 --> 00:03:06.100
middleware functions.

36
00:03:06.920 --> 00:03:11.700
For example, all these route functions are middleware functions so that before these

37
00:03:11.700 --> 00:03:14.880
functions become active, we check whether we have a valid token.

38
00:03:15.980 --> 00:03:18.320
If we don't, we send back an error response.

39
00:03:18.500 --> 00:03:22.860
If we do, we activate the next function, the next middleware in line.