So within our register controller here, we have our user actually being created already. And we know if we dive into our model for our user,

we're making use of the AuthFinder mixin, where we've defined our UID as well as our password column. And as the first argument, we're also providing a callback function

with the specific hash mechanism that we wanna use for our password. And if we dive into our browser and take a look at this AuthFinder mixin,

we'll see as the first parameter, it's accepting in a callback function with our hash mechanism as we just saw within our code, as well as options for the UIDs array, as well as the password column name here.

Then the AuthFinder is essentially a composable class mixin that will apply to the class that we're composing it into,

a before save hook that's in charge of using that hash mechanism that we provide in to hash our user's password column before it's actually saved into the database.

Which is why if we now dive into pgAdmin and head down to our tables for our user, right-click that, view edit data, and let's just select the first 100 rows here.

If we scroll over to their password column, it is hashed, and specifically it's hashed using script. So it's that with AuthFinder mixin that we're making use of

that's doing that automatically for us so that we don't need to worry about it. All that leaves for us to do whenever we're registering a user within our register controller is to log in that user.

So let's go ahead and get rid of our console lock here and let's log that user in. So first, what we're going to want to do is use the auth module out of our HTTP context.

With that, we can await auth.use our web guard to log in and provide in the user that we've created.

Once we have that, we will have created the user as well as log them into our application. So if we give that a save, jump back into our browser, let's head over to our register route and let's type some stuff in.

So we'll do auth user1, auth@test.com, and some valid password there. We'll hit enter and we're redirected back to our homepage.

Furthermore, if we take a look at our terminal, we don't see any errors. So how can we check to see whether or not our user is actually authenticated now?

We don't have anything currently denoting that the user is authenticated. Well, what we could do is hide away our login and register if they are, and instead maybe show their name. So let's hide our browser back away.

Let's jump down into our resources, views. Let's go into our nav partial and let's wrap these two anchors in an if.

So we'll do @if and we have globally available throughout Edge, auth, the same auth module that we have within our controllers,

and our authenticated users details will be populated on user. However, we'll see here in a second that this won't be the case for us quite yet.

So let's end if and then do an @else and plop the anchors that we've copied inside the else,

and we'll do auth user full name if the user is authenticated. So if they're authenticated, we should see their full name here. If they're not, then we'll see our login and register anchors.

Again, we have one more step to take care of to get this auth user to actually work. So if we were to dive into our browser at this point, give it a refresh, in the eyes of this request,

it doesn't know whether or not our user is actually authenticated because we haven't informed it to check for an authenticated user in the first place. So what we can do is dive up to our movies controller,

grab auth out of the index method for this, auth there, and we can now do await auth. and tell it to check for an authenticated user.

If it finds one, at this point onward, auth.user will be populated. Otherwise, it will just continue onward with auth user being null. Okay. So if we give that a save now,

jump back into our browser, give it a refresh. Okay, cool. So now we see auth user one up here. So the request is now noting that we are authenticated and has populated our auth.user.

However, we're only doing that for our index page. If we were to dive into, say, our writers, we're back to being logged out in the eyes of this particular request,

because we haven't checked for an authenticated user for this route. If we dive back into our home, there's our auth user again. Okay. So what we could do is let's remove auth check from our index page,

and instead, within our navigation where we're actually performing that check, we can do if await auth, and then just do check there,

and this will return back true if it does find a user or false if it does not. So it's essentially performing the same check here. Jump back into our browser, give it a refresh once more, and our auth user is still here.

But if we now dive into our writers, it now knows our auth user is there as well, because we're now informing it to check for that authenticated user.