.NET Core fundamentals in one picture.

How to disable “Register” action in ASP.NET Core?

This post was most recently updated on October 10th, 2020.

Reading Time: 4 minutes.

Sometimes you’ll need the default identity for your ASP.NET Core application, but want to disable the registration of new users. Sounds pretty basic, right? However, there’s actually no easy switch you can just flip to enable or disable said functionality.

I went through a lot of different articles and ideas by other people. Most of them involved fiddling with IdentityController, creating new scaffolded pages, adding new Actions with redirection code, and who knows what else… But who wants to fiddle with Identity? It’s glitchy and brittle enough that if you can, avoid customizing anything there.

Scaffolding:

ASP.NET Scaffolding is a code generation framework for ASP.NET Web applications. You add scaffolding to your project when you want to quickly add code that interacts with data models. Using scaffolding can reduce the amount of time to develop standard data operations in your project.

docs.microsoft.com

So, you’d better find a workaround!

Background of the issue

If you just search for “How to disable “Register” action in ASP.NET Core?” you do get a lot of results. Quite a few of them revolve around overriding multiple pages for the Identity -Area in your application. This requires scaffolding them first, and is just quite a pain.


Time needed: 30 minutes.

A great example of this would be “To disable user registration” -section of Microsoft’s documentation. It goes like this:

  1. Scaffold Identity. Include Account.Register, Account.Login, and Account.RegisterConfirmation.

  2. Update Areas/Identity/Pages/Account/Register.cshtml.cs so users can’t register from this endpoint

  3. Update Areas/Identity/Pages/Account/Register.cshtml to be consistent with the preceding changes

  4. Comment out or remove the registration link from Areas/Identity/Pages/Account/Login.cshtml

  5. Update the Areas/Identity/Pages/Account/RegisterConfirmation page.

    1. Remove the code and links from the cshtml file.
    2. Remove the confirmation code from the PageModel

Source: https://docs.microsoft.com/en-us/aspnet/core/security/authentication/scaffold-identity?view=aspnetcore-3.1&tabs=visual-studio#disable-register-page


That’s overall 5 steps, editing 4 different files, only after scaffolding 3 new items to your solution!

What an overkill, am I right?

Fact of the matter is, this is slow, to my experience prone to breaking, and ultimately, very unnecessary.

Why? Because there’s another workaround available!

Solution

Well, it’s actually a lot easier this way. No scaffolding required, no need to override any pages that you’d really not like to override.

In short, there’s just 2 things to do:

  1. We’ll want to disable the link to register, and
  2. Force a redirection away from the register form.

Achieving this is pretty simple. The following code changes are required.

Changes in _LoginPartial.cshtml:
@*<li class="nav-item">
  <a class="nav-link text-dark" asp-area="Identity" asp-page="/Account/Register">Register</a>
</li>*@

This’ll hide the Register -link from the LoginPartial for users that haven’t logged in.

How to disable the "Register" link from the LoginPartial.cshtml.
How to disable the “Register” link from the LoginPartial.cshtml.

Then you’ll need to take care to redirect anyone trying to access the Register -page. This’ll happen by adding 2 new routes like here:

endpoints.MapGet(“/Identity/Account/Register”, context => Task.Factory.StartNew(() => context.Response.Redirect(“/Identity/Account/Login”, true, true))); endpoints.MapPost(“/Identity/Account/Register”, context => Task.Factory.StartNew(() => context.Response.Redirect(“/Identity/Account/Login”, true, true)));

Below, you can see these changes in a larger context of Startup.cs -file.

Changes in Startup.cs:
using Microsoft.AspNetCore.Identity;

// The rest omitted for clarity

namespace Contoso.Web
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddDefaultIdentity<IdentityUser>()
                .AddEntityFrameworkStores<ApplicationDbContext>();

            // The rest omitted for clarity
        }

        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            // You probably have these already - critical for this to work, too:
            app.UseRouting();
            app.UseAuthentication();
            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapGet("/Identity/Account/Register", context => Task.Factory.StartNew(() => context.Response.Redirect("/Identity/Account/Login", true, true)));
                endpoints.MapPost("/Identity/Account/Register", context => Task.Factory.StartNew(() => context.Response.Redirect("/Identity/Account/Login", true, true)));

                // Omitted for clarity
            });
        }
    }
}

What does the code do, then? Well – it might be pretty self-explanatory, but let me clarify it anyway.

Obviously, you need to have configured Identity, Authorization and Authentication for .NET Core (the example above shows most of the groundwork). After that’s done, you’ll need to map the path – or route – “/Identity/Account/Register” for both GET and POST to execute a new Thread, that’ll then forcefully redirect the browser to “/Identity/Account/Login” instead. This’ll redirect all users clicking a “Register” link, trying to access the page with an address directly, or sending a POST request to the controller.

Okay, that’s a bit of a mouthful… But just give it a try and see how it works for you!

mm
0 0 vote
Article Rating
Subscribe
Notify of
guest
4 Comments
most voted
newest oldest
Inline Feedbacks
View all comments