At the moment we only have the API route
for logging users in.
We also need the front-end logic in the auth-form component.
There, we have to check whether we are logging in,
but we're not doing anything If we are.
Well, here we need to sign the user in.
And here we now don't need to send our own http request.
We don't need to configure it ourselves.
And we shouldn't.
Instead here we'll again import from next dash auth,
but now from next dash auth slash client.
And from there, we can import to signIn function.
This signIn function.
That's a function which we can call in our component
to send a signIn request.
And the request will be sent automatically.
So we just called signIn here
and now we can pass in some data here.
The first argument,
describes the provider
with which we wanna signIn.
Because we could have multiple providers,
in the same application.
Here, It's the credentials provider,
and hence we should write it like this.
Then we can also pass a second argument here.
That is a configuration object.
Now, where we can configure
how the signIn process should work.
And specifically here, we can add a redirect field
and set it to false.
You might remember that I said
that when nextauth is used here on the back-end,
in this API route,
that when we throw an Error here,
because authentication failed that by default,
next JS would redirect us to another page,
to an error page.
And to this something we could utilize,
we can then set up such an error page,
and we can configure that error page.
You can check out the next options
for the credentials provider to learn more about that.
But more often you typically wanna leave the user
on the page where he or she is
and just shows some error message there.
So, if we are logging in here,
I don't want to be redirected If it fails.
I maybe just want to show an overlay
or a little text here below the inputs.
And to avoid that we are redirected,
we can set redirect to false in that second argument
of the signIn method.
So, in this configuration object.
Now when setting redirect to false,
signIn we'll actually return up promise
which eventually yields us our result.
The promise will always resolve.
It will not be rejected.
Even if we have an error
in our back-end authentication code.
But if we had an error there,
result would be an object
that contains information about the error.
If we have no error during authentication,
result is still an object,
but without the error information.
So, this will never throw an Error.
It will never be rejected.
It's just a content of this result object,
which will differ.
And now besides passing redirect false,
we also wanna pass our credential data to the back-end.
We do descend this second argument as well
because it is actually the second argument as a whole,
which is received in our authorized function,
as this credentials argument here.
So this credentials parameter,
is that second argument which be passed to signIn.
And here I'm trying to access an email
and a password field.
And therefore to make sure that this works,
in auth-form besides setting redirect to false.
We should also add in the email
and set this to enteredEmail.
And add a password key and set this to enteredPassword.
And with that, we're sending this signIn request
and I'll now just log that result here.
And that's all we have to do when it comes
to signing users in.
If we now save everything,
we go back to that login page and reload it.
If I enter a valid email here,
but invalid password and I click login.
I get could not log you in.
Which makes sense
because that proves that we made it past this first check,
where we check for the general existence of a user.
But we then failed when we tried to get the password.
And you'll see what I meant.
We didn't get an error here.
Instead, we just have to get result object,
which has an error value.
Now If I do enter an invalid email address
which is not part of the database,
I get no user found.
Now, if I do enter valid credentials though,
then we see that error now is null.
So, now we got no error.
Instead we succeeded.
And that is how we can sign a user in.
Now we can create users and log them in.
And we get this yes, no response.
What we're not doing yet though, is working with that token
because of course in the front-end,
in our front-end components, when we get the result here,
we could now check if result error is falsey.
Which means we have no error, which means we've succeeded.
And we could then set some auth state,
maybe also with help auth react context or a Redux
and use that state to change what we see,
for example to change the options in our header.
We could now do that,
but whenever we reload that state would be lost,
because we start a brand new single page application
when we reload.
All the state, which was only stored
in memory from the last visit would be lost.
And that's not what we want.
That's also not what we have to accept
because that's exactly why we have this token concept.
We can store that token
in some more permanent storage than just our memory.
And we can then also use that token to send requests
to potentially protected APIs,
like the change password API
which we haven't implemented yet.
And therefore in the next lecture
let's now see how next JS helps us find
out whether a user is authenticated or not.
Starting on the client,
later also for the API routes