Aspnetcore.docs: Disable Registration .NET Core 2.1

[Kool-Koder]

Hi, I did not tag this to a particular post as I didn't encounter any official microsoft documentation talking about disabling registration. I did come across an issue in an archived version of .NET on github. https://github.com/aspnet/Identity/issues/1824

Even after reading this, I am unsure of what to do to ensure the registration and other unwanted pages is safely removed/hidden from the project and couldn't be attacked using a directory traversal brute force attack to guess the page for example. Hope to hear a safe solution from you soon! Thank you. :)

[Vutov]

This one seems to do the trick (tried it in core 3.0), not sure how safe it is.

    [Route("Identity/Account/Register")]
    [HttpGet]
    public IActionResult RegisterGet()
    {
        return Redirect("Identity/Account/Login");
    }

    [Route("Identity/Account/Register")]
    [HttpPost]
    public IActionResult RegisterPost()
    {
        return Ok();
    }

I'm looking forward for an official answer as well.

[Rick-Anderson]

@Kool-Koder aspnet/Identity#1824 is the definitive answer.

You can Scaffold Identity and remove the code you don't like.

[msstop]

Hi Everybody,

I have been working on the identity for days and just realised from Core 2.0 to 2.1 there is a huge difference. The file structure is completely as mentioned in https://devblogs.microsoft.com/aspnet/aspnetcore-2-1-identity-ui/

I am trying to use part of the framework and part of my own design but to do that I want to delete register but I do not have any file called register yet it is mentioned about deleting it at the referenced case. Am I missing the fact that there was a different methodology used to keep files local on that referenced issue?? It is very frustrating to figure out that it is the difference between 2.0 and 2.1. Such drastic changes with a point update.

One general feedback hoping someone on the team developing and deciding these stuff will read these: This is too much mate. Having such a drastic change, almost changing the entire architecture of the identity framework from Core 2.0 to 2.1 is too much. Maybe it is time for MS to slow down and think about how come all these new comers (languages and frameworks) surpassing its languages and frameworks. I am not a veteran programmer, I admit, but with so much changes it is even hard to follow only the versions let alone the functionality of the different versions. And it is frustrating. Feeling like why bother to learn, ,t will be changed completely and my knowledge will be obsolete. I don`t think php or java world changes this much. So frustrating:(

Hi @pwen090, thanks for contacting us.
Here is the answer to your questions:

What is the proper process for disabling user registration with this new razor library?

The simplest way to accomplish this is the one you mentioned. Simply override the register view, remove the code and have it for example, redirect to the login page.

public IActionResult OnGet() => RedirectToPage("/Account/Login");

Can you just delete these file[s] completely or will that then revert to the built-in razor library code?

If you remove the pages, it will revert to using the ones in the library. As a more involved option, you can remove the page actions using a pageapplicationmodelconvention.

Secondarily how does one disable the default identity razor class library all together so that there is no potential for attack surface creep in future updates or changes to said library? E.g. My authentication UI/Controllers are only what I have explicitly coded them to be. thank you!

@HaoK answer is the best way to do this.

Hope this helps!

Closing this issue as there's no further action to do here. Feel free to reopen if your problem hasn't been solved.

_Originally posted by @javiercn in https://github.com/aspnet/Identity/issues/1824#issuecomment-396335318_

[blackdwarf]

@Rick-Anderson so, in this document maybe add another section on "opting out" of this behavior and moving back to the previous, MVC behavior? This will help people that, like the OP and myself, are looking for ways to actually change/disable certain portions of the login mechanism. The correct way to do it is via @HaoK's suggestion.

[Rick-Anderson]

@blackdwarf I created #13263 to track this.