1
00:00:02,000 --> 00:00:04,000
At the moment we only have the API route

2
00:00:04,000 --> 00:00:06,000
for logging users in.

3
00:00:06,000 --> 00:00:10,000
We also need the front-end logic in the auth-form component.

4
00:00:10,000 --> 00:00:15,000
There, we have to check whether we are logging in,

5
00:00:15,000 --> 00:00:17,000
but we're not doing anything If we are.

6
00:00:17,000 --> 00:00:20,000
Well, here we need to sign the user in.

7
00:00:20,000 --> 00:00:25,000
And here we now don't need to send our own http request.

8
00:00:25,000 --> 00:00:27,000
We don't need to configure it ourselves.

9
00:00:27,000 --> 00:00:29,000
And we shouldn't.

10
00:00:29,000 --> 00:00:34,000
Instead here we'll again import from next dash auth,

11
00:00:35,000 --> 00:00:38,000
but now from next dash auth slash client.

12
00:00:39,000 --> 00:00:44,000
And from there, we can import to signIn function.

13
00:00:44,000 --> 00:00:46,000
This signIn function.

14
00:00:47,000 --> 00:00:50,000
That's a function which we can call in our component

15
00:00:50,000 --> 00:00:53,000
to send a signIn request.

16
00:00:53,000 --> 00:00:55,000
And the request will be sent automatically.

17
00:00:57,000 --> 00:00:59,000
So we just called signIn here

18
00:00:59,000 --> 00:01:02,000
and now we can pass in some data here.

19
00:01:02,000 --> 00:01:03,000
The first argument,

20
00:01:03,000 --> 00:01:05,000
describes the provider

21
00:01:05,000 --> 00:01:07,000
with which we wanna signIn.

22
00:01:07,000 --> 00:01:09,000
Because we could have multiple providers,

23
00:01:09,000 --> 00:01:11,000
in the same application.

24
00:01:11,000 --> 00:01:15,000
Here, It's the credentials provider,

25
00:01:15,000 --> 00:01:18,000
and hence we should write it like this.

26
00:01:18,000 --> 00:01:21,000
Then we can also pass a second argument here.

27
00:01:21,000 --> 00:01:23,000
That is a configuration object.

28
00:01:23,000 --> 00:01:26,000
Now, where we can configure

29
00:01:26,000 --> 00:01:28,000
how the signIn process should work.

30
00:01:28,000 --> 00:01:32,000
And specifically here, we can add a redirect field

31
00:01:32,000 --> 00:01:34,000
and set it to false.

32
00:01:34,000 --> 00:01:36,000
You might remember that I said

33
00:01:36,000 --> 00:01:39,000
that when nextauth is used here on the back-end,

34
00:01:39,000 --> 00:01:41,000
in this API route,

35
00:01:41,000 --> 00:01:43,000
that when we throw an Error here,

36
00:01:43,000 --> 00:01:47,000
because authentication failed that by default,

37
00:01:47,000 --> 00:01:49,000
next JS would redirect us to another page,

38
00:01:49,000 --> 00:01:51,000
to an error page.

39
00:01:51,000 --> 00:01:53,000
And to this something we could utilize,

40
00:01:53,000 --> 00:01:55,000
we can then set up such an error page,

41
00:01:55,000 --> 00:01:57,000
and we can configure that error page.

42
00:01:57,000 --> 00:02:00,000
You can check out the next options

43
00:02:00,000 --> 00:02:02,000
for the credentials provider to learn more about that.

44
00:02:02,000 --> 00:02:06,000
But more often you typically wanna leave the user

45
00:02:06,000 --> 00:02:08,000
on the page where he or she is

46
00:02:08,000 --> 00:02:11,000
and just shows some error message there.

47
00:02:11,000 --> 00:02:13,000
So, if we are logging in here,

48
00:02:13,000 --> 00:02:16,000
I don't want to be redirected If it fails.

49
00:02:16,000 --> 00:02:18,000
I maybe just want to show an overlay

50
00:02:18,000 --> 00:02:22,000
or a little text here below the inputs.

51
00:02:22,000 --> 00:02:25,000
And to avoid that we are redirected,

52
00:02:25,000 --> 00:02:29,000
we can set redirect to false in that second argument

53
00:02:29,000 --> 00:02:31,000
of the signIn method.

54
00:02:31,000 --> 00:02:33,000
So, in this configuration object.

55
00:02:33,000 --> 00:02:37,000
Now when setting redirect to false,

56
00:02:37,000 --> 00:02:39,000
signIn we'll actually return up promise

57
00:02:39,000 --> 00:02:42,000
which eventually yields us our result.

58
00:02:42,000 --> 00:02:44,000
The promise will always resolve.

59
00:02:44,000 --> 00:02:45,000
It will not be rejected.

60
00:02:45,000 --> 00:02:47,000
Even if we have an error

61
00:02:47,000 --> 00:02:50,000
in our back-end authentication code.

62
00:02:50,000 --> 00:02:51,000
But if we had an error there,

63
00:02:51,000 --> 00:02:53,000
result would be an object

64
00:02:53,000 --> 00:02:56,000
that contains information about the error.

65
00:02:56,000 --> 00:02:59,000
If we have no error during authentication,

66
00:02:59,000 --> 00:03:01,000
result is still an object,

67
00:03:01,000 --> 00:03:03,000
but without the error information.

68
00:03:03,000 --> 00:03:05,000
So, this will never throw an Error.

69
00:03:05,000 --> 00:03:07,000
It will never be rejected.

70
00:03:07,000 --> 00:03:10,000
It's just a content of this result object,

71
00:03:10,000 --> 00:03:11,000
which will differ.

72
00:03:12,000 --> 00:03:15,000
And now besides passing redirect false,

73
00:03:15,000 --> 00:03:19,000
we also wanna pass our credential data to the back-end.

74
00:03:19,000 --> 00:03:22,000
We do descend this second argument as well

75
00:03:22,000 --> 00:03:26,000
because it is actually the second argument as a whole,

76
00:03:26,000 --> 00:03:29,000
which is received in our authorized function,

77
00:03:29,000 --> 00:03:32,000
as this credentials argument here.

78
00:03:33,000 --> 00:03:34,000
So this credentials parameter,

79
00:03:34,000 --> 00:03:38,000
is that second argument which be passed to signIn.

80
00:03:38,000 --> 00:03:41,000
And here I'm trying to access an email

81
00:03:41,000 --> 00:03:43,000
and a password field.

82
00:03:43,000 --> 00:03:46,000
And therefore to make sure that this works,

83
00:03:46,000 --> 00:03:50,000
in auth-form besides setting redirect to false.

84
00:03:50,000 --> 00:03:52,000
We should also add in the email

85
00:03:52,000 --> 00:03:54,000
and set this to enteredEmail.

86
00:03:55,000 --> 00:03:59,000
And add a password key and set this to enteredPassword.

87
00:04:00,000 --> 00:04:03,000
And with that, we're sending this signIn request

88
00:04:03,000 --> 00:04:06,000
and I'll now just log that result here.

89
00:04:08,000 --> 00:04:10,000
And that's all we have to do when it comes

90
00:04:10,000 --> 00:04:12,000
to signing users in.

91
00:04:12,000 --> 00:04:14,000
If we now save everything,

92
00:04:14,000 --> 00:04:18,000
we go back to that login page and reload it.

93
00:04:18,000 --> 00:04:20,000
If I enter a valid email here,

94
00:04:20,000 --> 00:04:23,000
but invalid password and I click login.

95
00:04:23,000 --> 00:04:26,000
I get could not log you in.

96
00:04:26,000 --> 00:04:27,000
Which makes sense

97
00:04:27,000 --> 00:04:32,000
because that proves that we made it past this first check,

98
00:04:32,000 --> 00:04:36,000
where we check for the general existence of a user.

99
00:04:36,000 --> 00:04:40,000
But we then failed when we tried to get the password.

100
00:04:40,000 --> 00:04:41,000
And you'll see what I meant.

101
00:04:41,000 --> 00:04:43,000
We didn't get an error here.

102
00:04:43,000 --> 00:04:45,000
Instead, we just have to get result object,

103
00:04:45,000 --> 00:04:47,000
which has an error value.

104
00:04:49,000 --> 00:04:52,000
Now If I do enter an invalid email address

105
00:04:52,000 --> 00:04:54,000
which is not part of the database,

106
00:04:54,000 --> 00:04:56,000
I get no user found.

107
00:04:58,000 --> 00:05:01,000
Now, if I do enter valid credentials though,

108
00:05:01,000 --> 00:05:05,000
then we see that error now is null.

109
00:05:05,000 --> 00:05:06,000
So, now we got no error.

110
00:05:06,000 --> 00:05:08,000
Instead we succeeded.

111
00:05:08,000 --> 00:05:11,000
And that is how we can sign a user in.

112
00:05:12,000 --> 00:05:15,000
Now we can create users and log them in.

113
00:05:15,000 --> 00:05:18,000
And we get this yes, no response.

114
00:05:18,000 --> 00:05:22,000
What we're not doing yet though, is working with that token

115
00:05:22,000 --> 00:05:25,000
because of course in the front-end,

116
00:05:25,000 --> 00:05:29,000
in our front-end components, when we get the result here,

117
00:05:29,000 --> 00:05:34,000
we could now check if result error is falsey.

118
00:05:34,000 --> 00:05:38,000
Which means we have no error, which means we've succeeded.

119
00:05:38,000 --> 00:05:42,000
And we could then set some auth state,

120
00:05:42,000 --> 00:05:47,000
maybe also with help auth react context or a Redux

121
00:05:47,000 --> 00:05:50,000
and use that state to change what we see,

122
00:05:50,000 --> 00:05:54,000
for example to change the options in our header.

123
00:05:54,000 --> 00:05:56,000
We could now do that,

124
00:05:56,000 --> 00:05:59,000
but whenever we reload that state would be lost,

125
00:05:59,000 --> 00:06:02,000
because we start a brand new single page application

126
00:06:02,000 --> 00:06:04,000
when we reload.

127
00:06:04,000 --> 00:06:06,000
All the state, which was only stored

128
00:06:06,000 --> 00:06:09,000
in memory from the last visit would be lost.

129
00:06:09,000 --> 00:06:12,000
And that's not what we want.

130
00:06:12,000 --> 00:06:14,000
That's also not what we have to accept

131
00:06:14,000 --> 00:06:18,000
because that's exactly why we have this token concept.

132
00:06:18,000 --> 00:06:20,000
We can store that token

133
00:06:20,000 --> 00:06:24,000
in some more permanent storage than just our memory.

134
00:06:24,000 --> 00:06:29,000
And we can then also use that token to send requests

135
00:06:29,000 --> 00:06:31,000
to potentially protected APIs,

136
00:06:31,000 --> 00:06:33,000
like the change password API

137
00:06:33,000 --> 00:06:35,000
which we haven't implemented yet.

138
00:06:35,000 --> 00:06:37,000
And therefore in the next lecture

139
00:06:37,000 --> 00:06:41,000
let's now see how next JS helps us find

140
00:06:41,000 --> 00:06:45,000
out whether a user is authenticated or not.

141
00:06:45,000 --> 00:06:47,000
Starting on the client,

142
00:06:47,000 --> 00:06:50,000
later also for the API routes