For v6 and v7 sites

gistfile1.txt

using System.Web.Routing;
using Umbraco.Core;

namespace RemoveRoutes
{
    public class RemoveRoutesStartupHandler : ApplicationEventHandler
    {
        protected override void ApplicationStarted(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
        {
            // Reference: https://github.com/umbraco/Umbraco-CMS/issues/5206
            // Reference: https://shazwazza.com/post/need-to-remove-an-auto-routed-controller-in-umbraco/

            // Note: RouteTable needs System.Web.dll
            RouteTable.Routes.Remove(RouteTable.Routes["umbraco-surface-UmbRegister"]);
            RouteTable.Routes.Remove(RouteTable.Routes["umbraco-surface-UmbProfile"]);
            RouteTable.Routes.Remove(RouteTable.Routes["umbraco-surface-UmbLogin"]);
            RouteTable.Routes.Remove(RouteTable.Routes["umbraco-surface-UmbLoginStatus"]);
            RouteTable.Routes.Remove(RouteTable.Routes["umbraco-api-Tags"]);
        }
    }
}

This code breaks any member login functionality (that is used out of the box) on sites. We had a site that had members managed from the backoffice and after implementing this patch the login no-longer worked. Solution was to keep UmbLogin and UmbLoginStatus enabled. After that we groomed all registered members to ensure that there are no shady registrations that we don't recognize.

My question is - can this backfire, should we be careful about anything related to those controllers? There's not much information regarding UmbLogin and UmbLoginStatus apart that they could be used to exploit the Registration security hole.

@mkyukov - Indeed, it would break that. There's nothing all that harmful in the UmbLogin and UmbLoginStatus controllers, except if an attacker knows they exist then they could more easily try to perform a denial of service attack, especially for UmbLogin since each attempt will require some additional compute power. We added them to the list to be extra cautious mostly.

@nul800sebastiaan - Since we are having the same issue, Does your last comment means we are fine to keep UmbLogin and UmbLoginStatus enabled?

@nul800sebastiaan - Since we are having the same issue, Does your last comment means we are fine to keep UmbLogin and UmbLoginStatus enabled?

@nul800sebastiaan - Could you please advise on the question above, please?

@SarikaRansubhe - the UmbLogin and UmbLoginStatus actions to the best of our knowledge can not cause harm. However, we added them here since they could be used in a DOS attack, expecially UmbLogin.

We recommend you remove those routes and implement your own logic for handling a login and showing the login status. If you're not worried about DOS attacks then you could leave these two action a is.

Hi, do we delete the .cs file from App_Data once we run the website on the public server, or does it stay in there?

@bobi33 It has to stay in place.. it's the only thing protecting you if you do not upgrade to the latest version of Umbraco,