Okay so we've got our user models set up and tested and

we've got some validations in place for the email.

Now let's go ahead and say that our user model has

a secure password and see how that goes.

I am expecting everything to fail.

And it did because we are now missing the password digest.

Now what happens when we use this has_secure_password method is,

we get a couple virtual attributes on our user model.

Basically, what it's doing is saying, we've got an attribute for

password and password_confirmation.

And when somebody enters these, it's going to make sure they're both there and

that they match each other.

If it is, then it's going to encrypt those and

save it in the password digest attribute.

Now we don't have to worry about that,

because has_secure_password already does it for us.

However, what we are gonna need to do is change our valid attribute here

so that when these new models get created and saved, those validations run.

So we'll say password is treehouse1234.

And the password confirmation is also treehouse1234.

That's not my actual password, by the way.

My actual password has a five on the end of it.

Just kidding.

Let's go ahead and run that again and make sure it works.

Okay, good.

And let's go ahead and we'll add one more validation to make sure that the email

address looks like an email address.

So let's say, user.email is jason.

And we'll expect the user to not be valid.

Uh-oh, it was valid.

Well that makes sense, we haven't written anything yet.

So let's go ahead and add a format to it.

And this is just a regular expression that checks to make

sure we have some combination of valid characters and a @ sign.

As well as some valid combination of characters, a dot and

some other valid combination of characters.

Let's go ahead and run it again and make sure that that passes.

Okay, that looks good.

Let's run all of our tests and

see if anything else got messed up after we added the validations.

Wow, looks like we have a bunch more failures here inside of

the users_controllers_spec.

Let's go ahead and see what's going on there.

Well, it looks like we've got all these valid attributes in here as well.

So let's go ahead and fix all that.

So we've got first name, last name

We'll go ahead and set in password and password confirmation.

Okay, let's see if that fixed anything.

Looks like we still have a few failures here on line 68, 62, and 56.

So, let's go ahead and

see what's going on in the user's controller spec on these lines.

So, when we're posting to the create method, it is not changing the user count.

And, let's take a look at why.

And the reason actually has to do with strong parameters.

So we're requiring the user parameter, but

we're not sending along the password digest.

Instead we're sending along the password and the password confirmation.

Let's go ahead and run all that again and see what happens.

Okay, perfect.

Now we've done all of this,

but we don't know how this looks in the actual application just yet.

So let's go ahead and run our server and see what everything looks like.

So, if we go to local host, we've still got all of our to do list here.

This is still pretty separated from what's going on.

We have nothing going on with the users action because we removed it.

But if we go to user/new

we've got all these different fields for first name, last name, email and

password digest because that was what we created in the scaffold.

So let's go ahead, close all this, and fix that.

And that's going to be in our app > views > users directory.

We'll go ahead and edit the form.

Actually, if we go to its new page right here, let's say Register for ODOT.

All right, that looks much better.

So now instead of password_digest, what we want is password and

password confirmation.

And instead of being text fields, We want these to be password fields.

Okay.

That looks good.

Let's go back to this page here and reload it.

Okay, that looks nice.

Now before we actually do any of this, I'm gonna stop my server here and

let's go ahead and write a feature test for it.

So let's make a directory under spec/features/users and

we'll call this registration_spec.

Okay.

Close these files here.

Now let's go ahead and describe Signing up.

So what do we want to do?

It requires a user to sign up for the site.

So, let's go ahead and make sure we have no users here.

And we'll visit the root page, and you know what?

Let's expect the page to have the content sign up.

And when we click the sign up link, we'll get to that sign up form we just saw.

And we'll fill_in the First Name with Jason.

We'll fill_in

the Last Name with Seifer.

We'll fill_in the Email with jason@teamtreehouse.com,

that's one too many e's, but whatever.

And we'll make that say Password (again).

We'll click_button Sign Up.

And then we will expect the count of users to be one.

Now, there are a couple things here that have not been correctly mapped just yet,

so let's go ahead and watch that fail.

Okay, first thing we don't have the text sign up.

Let's go ahead and add that.

So here's our route.

So we've got the user resource there which means if we wanted to open up

our application layout, we could add another item here.

It says link_to Sign Up,

new_user_path.

Now let's see what happens.

Unable to find the field First Name.

Well, we saw that here, but actually if you look, it is lowercase.

So let's go ahead and edit our labels to make that look correct.

And we can do that by saying label :first_name, "First Name.",

just add a comma and that will change the label.

And instead of password confirmation we'll say Password (again).

And we'll change our submit button to say Sign-Up.

Now if we run that again, let's see what happens.

All right, that looks good.

Looks like we can actually register for the system.

In our next video,

we’re going to learn how to actually make that log us in to our account.