Do we really need to define a custom route for SignalR Hub?

I am reading the documentation for SignalR for v13 and my question is do we need to do the part for defining a custom route using the approach of IAreaRoutes ?

I thought in more recent versions of Umbraco the value to the Umbraco backoffice part could no longer be changed, if I have remembered correctly this seems extra bloat to the code and documentation if it could be simplified.

Docs

Section I am not sure we need?

using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Umbraco.Cms.Core.Composing;
using Umbraco.Cms.Core.DependencyInjection;
using Umbraco.Cms.Web.Common.ApplicationBuilder;
using Umbraco.Extensions;

public class TestHubRoutes : IAreaRoutes
{
    private readonly IRuntimeState _runtimeState;
    private readonly string _umbracoPathSegment;

    public TestHubRoutes(
        IOptions<GlobalSettings> globalSettings,
        IHostingEnvironment hostingEnvironment,
        IRuntimeState runtimeState)
    {
        _runtimeState = runtimeState;
        _umbracoPathSegment = globalSettings.Value.GetUmbracoMvcArea(hostingEnvironment);
    }

    public void CreateRoutes(IEndpointRouteBuilder endpoints)
    {
        switch (_runtimeState.Level)
        {
            case Umbraco.Cms.Core.RuntimeLevel.Run:
                endpoints.MapHub<TestHub>(GetTestHubRoute());
                break;
        }

    }

    public string GetTestHubRoute()
    {
        return $"/{_umbracoPathSegment}/{nameof(TestHub)}";
    }
}

Could it be simplified like so?

using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Umbraco.Cms.Core.Composing;
using Umbraco.Cms.Core.DependencyInjection;
using Umbraco.Cms.Web.Common.ApplicationBuilder;
using Umbraco.Extensions;

public class TestHubComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        // first we are going to add signalR to the serviceCollection if no hubs have been added yet
        // this is just in case Umbraco ever decides to use a different technology
        if (!builder.Services.Any(x => x.ServiceType == typeof(IHubContext<>)))
        {
            builder.Services.AddSignalR();
        }
        
        // next is adding the routes we defined earlier
        builder.Services.AddUnique<TestHubRoutes>();
        builder.Services.Configure<UmbracoPipelineOptions>(options =>
        {
            options.AddFilter(new UmbracoPipelineFilter(
                "test",
                 endpoints: applicationBuilder =>
                {
                    applicationBuilder.UseEndpoints(e =>
                    {
                       // NEW: We know the path of umbraco can not be changed
                       // and using IAreaRoutes to calculate the path seems overkill ?
                       e.MapHub<TestHub>($"/umbraco/{nameof(TestHub)}";

                       // Previous code
                       // var hubRoutes = applicationBuilder.ApplicationServices.GetRequiredService<TestHubRoutes>();
                       // hubRoutes.CreateRoutes(e);
                    });
                }
            ));
        });
    }
}

Clarification

So can anyone confirm that perhaps this is no longer needed and in fact we can not configure the path of Umbraco anymore?

Just heard back from Seb at HQ that the path to Umbraco can no longer be configured since version 9 and gave me a link back to this GitHub issue comment

Since this question comes up some times, I’ve summarized the reason why this was done. I know the people commenting here don’t accept that you can’t customize the path any more, so no need to comment that you don’t like it, trust me, we know! :sweat_smile:

Over the years, we have had many issues reported with plugins not working because the URL of the backoffice was renamed. This could be overcome by extra care and attention from plugin developers, but it’s been a struggle as those developers don’t know to expect the name change.

The breaking point for us (as Umbraco HQ) came when we wanted to move towards using Razor Class Libraries (RCLs) for the backoffice assets. RCLs provide a much more robust way of installing and deploying NuGet packages that contain static assets, making the developer experience better. The trade-off here: we can’t rename the directory from Umbraco to something else.

Additionally, the same plugin developers that already knew to look for sites changing the /umbraco URL were for the same reason unable to use RCLs for their packages, for the exact same reason, the umbraco path has to be consistent for this to work.

Unfortunately, we didn’t see a way out of this and we weighed reliable installs and deploys against the obscuring of the Umbraco path. Realizing that there are very robust ways to protect the backoffice, even if it is on a predictable path, was the biggest factor in deciding to lean towards a better install/deploy experience vs the relatively small amount of people wanting to customize the backoffice URL.

So I will make a PR back to docs, as I feel this part of the code is not needed and extra bloat IMO and update this thread.

One PR back to the V13 docs

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.