All language subtitles for 010 Sending a _Signin_ Request From The Frontend_Downloadly.ir_en

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