Sometimes, for security reasons, you might want to generate passwords for your users instead of letting them choose one. In this article, I will take a look at how to handle this process in ASP.NET Core. For simplicity, I will make use of the ASP.NET Identity framework, but you can apply no matter how you decided to handle user accounts in your application. If you want to also user the Identity framework, make sure to press the Change Authentication button when you create a new project and select Individual User Accounts:
If you want to know more about creating and deploying an ASP.NET application, you can check my article on that subject.
For this tutorial, I will present a simple example where registering as a new user only requires a username and a password. Thus, I will use the same model for both the registration and the login process. If you require more information for the registration, you should create separate models. This is what my model looks like:
Next up, I will create the controller that will handle the authentication and call it AuthController. Since this controller will work with creating and signing users in, I will inject several dependencies into it. This should work automatically if you use the Identity framework, but take a look at this article if you want to learn more about dependency injection in ASP.NET. This is what the controller looks like so far:
Generating a password
Since in this tutorial I want to call the method that generates the password from the view, I will create it as an action in AuthController. If you want to use it in some other way, such as generating the password and setting it through e-mail after registration, you can make it private. This is what the password generation looks like:
First of all, we get all the requirements for the password: the length and the mandatory character types. After that, we keep adding random characters until the length requirements is fulfilled, while keeping track of what kind of characters we added. Once we have the necessary length, we check for character types that the random generation might have missed, and add them to the StringBuilder object. You can read more about why it’s better to use a StringBuilder instead of a String in this article.
Creating the registration process
Now that the password generation is ready, we can move on to the actual registration process. First up, I will create a GET and a POST method in AuthController, for generating the view and handling the actual registration.
The GET method simply returns the view, but you can eventually add some logic to it, such as checking if the user is already logged in before rendering the view . The POST method, which receives data from the form that we will create later, checks if the username already exists and, if it does not, creates a new user. It redirects the user to the Index page if the creation is successful, or it reloads the Register page if something went wrong.
Now that we have this in place, we can create the actual form that the user will fill in. Right click on the GET method and choose Add view…. On the window that pops up, choose Create as the template and UserRegisterModel as the model class.
An important thing to pay attention to is the event.preventDefault() line from the generatePassword function. This will prevent the window to refresh after sending the GET request to the controller. If you followed everything, this is the view that you should see by going to the /auth/register endpoint:
Testing with a login
To properly check the generation and wrap this tutorial, I will also create a login process. Same as for the registration, I will create a GET and a POST method. As mentioned earlier, I will use the same UserRegistrationModel, but make sure you separate them if you need different information in each.
Again, the POST method checks if the user exists, but this time, it reloads the view if it doesn’t. After that, we use the SignInManager class to sign in the user and redirect to the Index page if everything goes well.
To generate the login view, right click the GET method and choose Add View... In my case, I had to choose the same options as earlier, but make sure to select the model that you use in your POST method. You can leave this view to its default.
As I mentioned before, you can also use this password generation approach to do something like sending it to the user through e-mail. If you don’t consider this to be safe, you can also generate a random password and then send the user a “reset password” link upon registration. You can tailor this to suit your needs, but the core idea regarding the random password remains the same.
If you are interested, you can find all the code from this article on GitHub.