1
00:00:02,000 --> 00:00:04,000
Now to take a closer look at API routes

2
00:00:04,000 --> 00:00:06,000
and how we can protect those,

3
00:00:06,000 --> 00:00:09,000
I will take this change password example.

4
00:00:09,000 --> 00:00:13,000
This clearly is an operation that should be restricted.

5
00:00:13,000 --> 00:00:17,000
Not every user should be allowed to change a password.

6
00:00:17,000 --> 00:00:20,000
It only makes sense for authenticated users

7
00:00:20,000 --> 00:00:22,000
and hence, I will add a new API route

8
00:00:22,000 --> 00:00:26,000
and we can add it in the API auth folder,

9
00:00:26,000 --> 00:00:28,000
but we could also add it somewhere else,

10
00:00:28,000 --> 00:00:32,000
and to show that it does not have to be in the auth folder,

11
00:00:32,000 --> 00:00:36,000
I will create another folder, in the pages API folder,

12
00:00:36,000 --> 00:00:38,000
and that will be the user folder,

13
00:00:38,000 --> 00:00:41,000
but you could add it in auth, as well,

14
00:00:41,000 --> 00:00:45,000
and in there, I'll add the change-password.js file

15
00:00:45,000 --> 00:00:47,000
because I want to create an API route,

16
00:00:47,000 --> 00:00:50,000
which can be reached by sending a request

17
00:00:50,000 --> 00:00:54,000
to /api/user/change-password,

18
00:00:54,000 --> 00:00:56,000
that's reaching this file then.

19
00:00:57,000 --> 00:01:01,000
Now in this file, we're not going to use NextAuth,

20
00:01:01,000 --> 00:01:03,000
at least not as we did it

21
00:01:03,000 --> 00:01:06,000
in this square bracket nextauth file.

22
00:01:06,000 --> 00:01:09,000
Instead, we're going to create our own API route,

23
00:01:09,000 --> 00:01:12,000
just as we learned it in this course.

24
00:01:12,000 --> 00:01:14,000
So I'll create a handler function here,

25
00:01:14,000 --> 00:01:17,000
which gets a request and a response,

26
00:01:17,000 --> 00:01:20,000
and I'll then export this as a default here,

27
00:01:21,000 --> 00:01:24,000
and now in this handler function,

28
00:01:24,000 --> 00:01:28,000
we want to extract the old and new password,

29
00:01:28,000 --> 00:01:30,000
which the user entered here.

30
00:01:31,000 --> 00:01:33,000
We want to verify that the request is coming

31
00:01:33,000 --> 00:01:36,000
from an authenticated user

32
00:01:36,000 --> 00:01:39,000
and deny for reaction, if it's not.

33
00:01:39,000 --> 00:01:41,000
We want to get the email address

34
00:01:41,000 --> 00:01:43,000
of that authenticated user then,

35
00:01:43,000 --> 00:01:46,000
and then we want to look into the database,

36
00:01:46,000 --> 00:01:49,000
see if we find that user there,

37
00:01:49,000 --> 00:01:52,000
see if the old password that was entered matches

38
00:01:52,000 --> 00:01:54,000
the current password in the database,

39
00:01:54,000 --> 00:01:56,000
and if that's the case,

40
00:01:56,000 --> 00:01:59,000
we want to replace that old password with the new password.

41
00:01:59,000 --> 00:02:01,000
So that's what we're now going to do

42
00:02:01,000 --> 00:02:03,000
over the next minutes.

43
00:02:03,000 --> 00:02:05,000
Now for that, in the handler function,

44
00:02:05,000 --> 00:02:07,000
the change-password.js file here,

45
00:02:07,000 --> 00:02:10,000
let's first of all, check if the incoming request

46
00:02:10,000 --> 00:02:13,000
has the right method, and for changing the password,

47
00:02:13,000 --> 00:02:18,000
a POST, or a PUT, or a PATCH request makes sense.

48
00:02:18,000 --> 00:02:21,000
These are the three kinds of requests that imply

49
00:02:21,000 --> 00:02:26,000
that resources on the server should be created or changed,

50
00:02:26,000 --> 00:02:29,000
and you can argue whether changing a password

51
00:02:29,000 --> 00:02:32,000
is creating a new resource, a new password,

52
00:02:32,000 --> 00:02:36,000
or changing an existing resource and existing user,

53
00:02:36,000 --> 00:02:39,000
and I will go for the latter argument,

54
00:02:39,000 --> 00:02:43,000
and I want to say that I only want to continue here,

55
00:02:43,000 --> 00:02:47,000
if the incoming request has a method of PATCH.

56
00:02:47,000 --> 00:02:51,000
So if it's not PATCH, then we will just return

57
00:02:51,000 --> 00:02:53,000
and not continue at all.

58
00:02:53,000 --> 00:02:56,000
We will only continue for PATCH requests,

59
00:02:56,000 --> 00:02:59,000
which of course means that in the front-end,

60
00:02:59,000 --> 00:03:02,000
so in our client-side code, we'll have to make sure

61
00:03:02,000 --> 00:03:07,000
that we do send a PATCH request to this API route later.

62
00:03:08,000 --> 00:03:09,000
So that's check number one.

63
00:03:10,000 --> 00:03:14,000
Check number two, is whether that request is coming

64
00:03:14,000 --> 00:03:17,000
from an authenticated user or not,

65
00:03:17,000 --> 00:03:21,000
and if it's not, we also want to return with an error,

66
00:03:21,000 --> 00:03:23,000
and for this, we can again use

67
00:03:23,000 --> 00:03:26,000
this getSession function here,

68
00:03:26,000 --> 00:03:29,000
which we already used on the profile page.

69
00:03:29,000 --> 00:03:33,000
There we are already using it in server-side code,

70
00:03:33,000 --> 00:03:34,000
inside of getServerSideProps.

71
00:03:35,000 --> 00:03:38,000
So we already see that it runs on the server,

72
00:03:38,000 --> 00:03:40,000
as well as on the client,

73
00:03:40,000 --> 00:03:42,000
and that of course means that we can again,

74
00:03:42,000 --> 00:03:47,000
use it in our API route, which also is server-side code.

75
00:03:47,000 --> 00:03:49,000
So therefore, in the change-password.js file,

76
00:03:49,000 --> 00:03:54,000
I will again, import getSession from next-auth/client.

77
00:03:58,000 --> 00:04:02,000
The /client can be confusing, but this does work

78
00:04:02,000 --> 00:04:04,000
on the server, as well, as we saw,

79
00:04:04,000 --> 00:04:08,000
and then we want to check if we do get a session.

80
00:04:08,000 --> 00:04:11,000
For this we can store a session a constant,

81
00:04:11,000 --> 00:04:13,000
and we get it by calling getSession,

82
00:04:13,000 --> 00:04:16,000
and then as you learned, on the server-side,

83
00:04:16,000 --> 00:04:20,000
we can pass in an object where we set the req key

84
00:04:20,000 --> 00:04:22,000
to the request we're getting here.

85
00:04:23,000 --> 00:04:25,000
GetSession needs that incoming request,

86
00:04:25,000 --> 00:04:28,000
because it will then look into that request,

87
00:04:28,000 --> 00:04:31,000
see if a session token cookie is part of the request.

88
00:04:31,000 --> 00:04:34,000
If it is, it will validate and extract that data

89
00:04:34,000 --> 00:04:37,000
from that cookie, and if that all then makes sense,

90
00:04:37,000 --> 00:04:39,000
it will give us the session object.

91
00:04:40,000 --> 00:04:43,000
Now, getSession actually returns a promise,

92
00:04:43,000 --> 00:04:44,000
and to use async await,

93
00:04:44,000 --> 00:04:47,000
I'll turn this into a async function

94
00:04:47,000 --> 00:04:48,000
and I'll wait here.

95
00:04:49,000 --> 00:04:52,000
So now we get our session,

96
00:04:52,000 --> 00:04:55,000
or we don't get one if the user is not authenticated,

97
00:04:55,000 --> 00:04:57,000
and therefore, we can check if not session,

98
00:04:57,000 --> 00:04:59,000
if that's undefined,

99
00:04:59,000 --> 00:05:02,000
which means the request is not authenticated,

100
00:05:02,000 --> 00:05:04,000
and in that case, we also want to return

101
00:05:04,000 --> 00:05:08,000
and here, we may be also want to send back a response.

102
00:05:08,000 --> 00:05:11,000
We could send one back in this first if check as well,

103
00:05:11,000 --> 00:05:13,000
a special response,

104
00:05:13,000 --> 00:05:15,000
but I don't care about that here, but here,

105
00:05:15,000 --> 00:05:18,000
I actually do want to send back a response

106
00:05:18,000 --> 00:05:21,000
with a status code of 401,

107
00:05:21,000 --> 00:05:24,000
which basically is the standard status code

108
00:05:24,000 --> 00:05:28,000
for saying that authentication is missing,

109
00:05:28,000 --> 00:05:30,000
and then possibly some extra data attached,

110
00:05:30,000 --> 00:05:34,000
like a message of not authenticated,

111
00:05:34,000 --> 00:05:35,000
but of course, it's up to you,

112
00:05:35,000 --> 00:05:39,000
which kind of data, if any, you want to send back.

113
00:05:40,000 --> 00:05:42,000
So that's now another important check,

114
00:05:42,000 --> 00:05:45,000
and that is the key check of this module,

115
00:05:45,000 --> 00:05:47,000
of this course module,

116
00:05:47,000 --> 00:05:51,000
because this line here or this block of code,

117
00:05:51,000 --> 00:05:55,000
that's the code where we validate whether a request

118
00:05:55,000 --> 00:05:57,000
is authenticated or not.

119
00:05:57,000 --> 00:06:02,000
This is the code with which we protect our API route

120
00:06:02,000 --> 00:06:04,000
against unauthenticated access,

121
00:06:04,000 --> 00:06:08,000
and every API route that does something

122
00:06:08,000 --> 00:06:12,000
that should only be allowed to authenticated users,

123
00:06:12,000 --> 00:06:14,000
needs code like this.

124
00:06:14,000 --> 00:06:17,000
Everything else we're going to write in this API route

125
00:06:17,000 --> 00:06:21,000
is not directly related to authentication.

126
00:06:21,000 --> 00:06:24,000
Yes, we're going to change the password of a user,

127
00:06:24,000 --> 00:06:27,000
and that of course, has something to do with authentication,

128
00:06:27,000 --> 00:06:30,000
but on the other hand, changing a password is really not

129
00:06:30,000 --> 00:06:32,000
that different from creating a product.

130
00:06:32,000 --> 00:06:35,000
We're just changing some data in the database in the end.