This course will be retired on June 1, 2025.
Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Now the moment you've been waiting for—testing our changes!
Preventing Duplicate Users
Our registration form currently allows users to register with an email address that's already associated with an existing account. We can update the AccountController.Register POST action method to validate if an email address is already in use or not.
Using the ASP.NET Identity UserManager Class
Identity's UserManager class provides a wide variety of methods related to users. To determine if an existing account is associated with an email address, we can use the FindByEmail or FindByEmailAsync method to search for a user by their email address. If a user is returned, then we know the provided email address is in use. All we need to do then, is to add the model error.
// Validate if the provided email address is already in use.
var existingUser = await UserManager.FindByEmailAsync(viewModel.Email);
if (existingUser != null)
{
ModelState.AddModelError("Email", $"The provided email address '{viewModel.Email}' has already been used to register an account. Please sign-in using your existing account.");
}
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
We've made solid progress.
0:00
Now the moment you've been waiting for,
testing our changes.
0:02
Well, hold onto that thought for
just another moment or two.
0:06
Before we debug our web app,
0:10
there's a couple of quick things
that we need to take care of.
0:11
If you have an existing FitnessFrog
database, you'll need to delete it first
0:15
before you attempt to run the application,
otherwise you'll get an error.
0:19
I'll quick into Quick Launch and type SQL.
0:24
Then I'll select
SQL Server Object Explorer.
0:29
I'll click on the refresh button
then expand MSSQLLocalDB and
0:34
Databases, and
here is my existing FitnessFrog database.
0:39
I'll right click on it, select Delete, and
check Close existing connections, and OK.
0:43
And then my database is gone.
0:50
I'll close this window,
done with it for now, and
0:53
we're ready to make our next change.
0:55
Earlier, we disabled owin,
now we need to enable it so
0:58
our identity middleware
component will be able to run.
1:01
In the route of our project,
go ahead and open the Web.config file.
1:05
Scroll down a bit and look for
the appSettings section, and
1:12
in particular,
the owin:AutomaticAppStartup setting.
1:15
Currently, it's set to false.
1:20
Let's change that to true and
save and close the file.
1:22
Now, let's debug the app and take a look
at our finished user registration page.
1:27
Here's our homepage,
showing a list of the available entries.
1:34
To get to the user registration page, we
can simply click on the Register button.
1:38
And here's our user registration page.
1:43
Let's test our client-side validation.
1:46
I'm not gonna provide any values,
I'll just click the Register button.
1:49
Well, that's encouraging.
1:54
We're being asked to provide our email and
password fields, so
1:55
we know our required field
validations are working.
1:59
I'll provide an email address and
for the password I'm going to type
2:02
a single letter, the character P,
and click Register.
2:04
Now we're being told that our password
must be at least 6 characters long, and
2:09
that our password and
confirmation password values don't match.
2:14
Well, that makes total sense, we didn't
even provide a confirm password value.
2:19
So let's fix the problem.
2:24
For my password,
I'll type password, and for
2:25
a confirm password,
I'll type password again.
2:29
Now we're getting all green check marks.
2:33
But before I click Register,
I'm gonna go back to Visual Studio.
2:35
And in Solution Explorer,
I'm going to expand Controllers and
2:40
open up AccountController.
2:44
I'm going to scroll down to
the Register post action method and
2:49
just inside of that method on line 38
here, I'm going to set a break point.
2:53
Back in Chrome,
I'll click Register to submit the form.
2:59
Okay, here we are at our break point.
3:04
Now let's step through the code.
3:07
Our model state is valid.
3:09
So we move into that block and we
instantiate an instance of the User class.
3:11
Now we're just about ready to call
the _userManager.CreateAsync method,
3:17
which will create our
user in the database.
3:21
The result was successful, so
3:26
we can see that the succeeded
property is set to true.
3:28
And if we step to the next line of code,
3:31
we're ready to call the signInManager's
SignInAsync method.
3:34
Now we're signed in and
3:39
we're going to redirect the user
back to the entry's index route.
3:41
Press F5 to continue execution.
3:46
Now we're back at our homepage.
3:49
But what's changed?
3:51
Notice that now we're seeing
the add entry and sign out buttons.
3:52
This is because identity after creating
our account and signing this in,
3:57
sent an authentication cookie back to
the client as part of the response.
4:02
This allowed the authentication cookie to
be sent back to the server with the next
4:07
request, the request here for
the homepage.
4:11
And remember,
if we take a look at our layout page.
4:15
Views > Shared > Layout.
4:21
Here in our Layout page,
we're checking to see if
4:25
the Request.IsAuthenticated
property is set to true.
4:29
And if it is, we display or
render the Add Entry and Sign Out buttons.
4:33
Else, we display the Register and
Sign In buttons.
4:43
We can use Google Chrome's DevTools to
actually take a look at the authentication
4:49
cookie itself.
4:54
Here in this tabbed interface,
I'm gonna select Application and
4:59
then over on the left we have a Cookies
folder, and then we have cookie here for
5:03
our localhost domain.
5:08
Make that column a little wider and
we can see the name of our cookie.
5:11
AspNet.AplicationCookie, and
5:14
to the right of that,
we can see the value of the cookie.
5:17
The value of the cookie is our
encrypted identity information.
5:21
If we delete the authentication cookie and
5:25
then go back to the browser and
refresh the page.
5:29
Notice that the menu switches back to
showing the Register and Sign In buttons.
5:33
This is happening because we deleted
our authentication cookie, so
5:38
it's no longer available
to send back to the server.
5:42
That resulted in
the Request.IsAuthenticated property
5:45
being set to false.
5:49
Which then, in our layout view,
rendered the Register and Sign In buttons.
5:50
Something else worth knowing, if we browse
back to our user registration page.
5:54
Currently, it's possible
right now to register again
5:59
using the same email address
that we used last time.
6:02
It's totally possible to be able to
prevent this using server-side validation.
6:06
If you'd like to see how to do that,
check out the teacher's notes.
6:10
This is great, now we have a way for our
users to register with our web app, but
6:14
we need to add a way for
registered users to sign in.
6:19
That's what we'll do in the next section.
6:22
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up