Added configuration option UseStrictDomainMatching, which allows control over whether content is routed without a matching domain

[AndyButland]

Prerequisites

• I have added steps to test this contribution in the description below

Addresses: #19010

Description

The linked issue describes two concerns, only only one of which I could replicate, and which is addressed in this PR.

I've used the following setup:

With these domains:

• Site A Home - localhost:44339
• Site B Home - localhost:44340

I've then configured Umbraco to launch with these URLs (in Program.cs):

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

builder.WebHost.UseUrls("https://localhost:44339", "https://localhost:44340", "https://localhost:44341");

Navigating to the following pages gives these results:

• https://localhost:44339/sample-page/ - renders page
• https://localhost:44339/sample-page-2/ - renders page
• https://localhost:44340/sample-page/ - renders page
• https://localhost:44340/sample-page-2/ - returns 404
• https://localhost:44341/sample-page/ - renders page (from Site A).

The issue is reporting two things:

1. That when requesting a page under a domain, where the domain exists but the page doesn't, and it does exist under the root node - it'll return that. However I can't replicate this.
2. That when requesting a page under a domain, where the domain doesn't exist, and it does exist under the root node - it'll return that. This one I can see and as, per the linked issue, it likely isn't what you want.

So this PR addresses the second issue. I considered it would be breaking to change this behaviour, and are situations where the current behaviour is desired (not least, when no domains are configured), so have introduced a new configuration option:

  "WebRouting": {
    "UseStrictDomainMatching": true
  },

This defaults to false, which keeps the current behaviour. When set to true, the page won't be routed if a domain is not found and attached to the request provided to the content finder.

With that we get the following results:

• https://localhost:44339/sample-page/ - renders page
• https://localhost:44339/sample-page-2/ - renders page
• https://localhost:44340/sample-page/ - renders page
• https://localhost:44340/sample-page-2/ - returns 404
• https://localhost:44341/sample-page/ - returns 404

Testing

Review and verify what's described above.

[Copilot]

Pull Request Overview

This PR introduces a new configuration option UseStrictDomainMatching to control whether content is routed when there's no matching domain configured. The change addresses an issue where requests to domains that don't exist in the Umbraco configuration would still route to content under the root node, which may not be the desired behavior in multi-domain setups.

Key changes:

• Added UseStrictDomainMatching configuration option (defaults to false for backward compatibility)
• Modified ContentFinderByUrlNew to respect the new setting and return 404 when strict matching is enabled and no domain is found
• Added comprehensive unit tests to verify the new behavior

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
WebRoutingSettings.cs	Adds the new UseStrictDomainMatching configuration property with documentation
ContentFinderByUrlNew.cs	Implements the strict domain matching logic and adds new constructor for dependency injection
ContentFinderByUrlNewTests.cs	Provides comprehensive unit test coverage for the new functionality

Comments suppressed due to low confidence (1)

src/Umbraco.Core/Routing/ContentFinderByUrlNew.cs:29

• The obsolete attribute references 'Umbraco 18' but based on the current major version patterns in Umbraco, this version number may not align with the actual versioning scheme. Consider verifying the correct version number for the scheduled removal.

    [Obsolete("Please use the constructor with all parameters. Scheduled for removal in Umbraco 18.")]

[BenWhite27]

@AndyButland Thanks for adding this setting, it looks like it will work and improve multi-site installations. Just one really, really nitpicky comment I've added.

I was also unable to reproduce the other part of my issue in a clean installation. I reckon the behavior I saw was routes for an unmatched domain falling back to the first matching path in any site. During my testing I probably got confused with what domain I was using and tested with an unmatched one instead of a matched domain.

[AndyButland]

Good to hear @BenWhite27, thanks for looking over.