Remove default auto-routes

Questions
1

I wonder what the best approach is the remove auto-routes created by Umbraco in v13?

For the specific use-case to remove routes in backend used in headless project, e.g. for a Settings node, we don’t really need the route /settings

This is an old an old article by Shannon, but a bit outdated.

We can probably also set 404 in request pipeline, but ideally I think it may be better to remove the auto-route.

It will probably be sufficient to handle this based on content type, eventually a config in appsettings.json or just a hardcoded list in the code.

2

Hey there :slightly_smiling_face:

I know this might not directly answer your question, but what about changing which is the start node for routing?

Screenshot_20250924_182835
Screenshot_20250924_1828351148×803 91.7 KB

With the approach shown in the image above, only Home and it’s sub-pages are routable.
This way you don’t have to do some “hacky” stuff to get around the default routing setup.

I personally use this setup for all who might need this kind of non-routable behavior.
It ensures that it’s always following Umbraco and I don’t have to change my implementation if Umbraco decide to change anything with routing.

It also scales to any number of sites you might want to have on a Umbraco instance.

3

The other nodes (at root) without hostname will still have a route by default with DefaultUrlProvider.

I figured out I can add a CustomUrlProvider inheriting DefaultUrlProvider similar to this and for specific content types return null.

To ensure it doesn’t still use DefaultUrlProvider then remove than one and insert the custom one in a composer:

public void Compose(IUmbracoBuilder builder)
{
    builder.UrlProviders()
        .Remove<DefaultUrlProvider>();
        .Insert<CustomUrlProvider>();
}

Howeever since the frontend is headless, it didn’t prevent from fetching content by path or id:

/umbraco/delivery/api/v2/content/item/settings
/umbraco/delivery/api/v2/content/item/95145de5-5fdd-4b5b-91c7-a06cd0e3cd3a

Instead we have handle that part in Nuxt when it fetch content by path.

1 Like
4

Sick!

As for the ability to still query content directly, could this maybe be solved by just adding a Public Access Restriction to the nodes?

5

We still need to fetch data from settings node via Delivery API, just not render the page/node directly at the same path from [...slug].vue in Nuxt 3 and Vue 3.

1 Like