UrlProviderMode Absolute not honered during routing

[BenWhite27]

Which Umbraco version are you using?

15.4.0-rc.preview.40

Bug summary

The ContentFinderByUrlNew content finder does not seem to check the UrlProviderMode setting during routing.

When a request is processed and a domain match was not found, the content finder makes use of the default IDocumentUrlService implementation which then falls back to the first root content node here.

Umbraco-CMS/src/Umbraco.Core/Services/DocumentUrlService.cs

Line 534 in 97b3023

return GetTopMostRootKey(isDraft, culture);

Specifics

My project hosted in Umbraco Cloud has multiple sites and domains, I'm trying to prevent the default project-name.uksouth01.umbraco.io domain from successfully routing through to any public facing website. I'm also trying to prevent domain1.com/some-page from routing through to domain2.com/some-page when it doesn't exist on the first site.

The UrlProviderMode seems to have replaced the older useDomainPrefixes setting from earlier versions of Umbraco. From researching the forums this older prefix setting seemed to match the behavior I'm looking for above.

Steps to reproduce

Create two root content nodes and assign them each a domain. Set the UrlProviderMode setting to Absolute, and test if a 3rd, unassigned domain can route through to content.

Expected result / actual result

The unassigned domain should get a 404 response when the UrlProviderMode is set to Absolute.

---

This item has been added to our backlog AB#51885

[github-actions]

Hi there @BenWhite27!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[umbracocommunity]

This issue has been mentioned on Umbraco community forum. There might be relevant details there:

https://forum.umbraco.com/t/how-to-setup-strict-domain-handling-in-a-multisite-installation/2673/2

[AndyButland]

Just following up on this on @BenWhite27, as I see there has been some more discussion and your reports of progress with this on the forum. To make any changes to how the shipped URL provider works would likely be a breaking change, so we'd have to be quite careful over it - and it sounds like you may have been able to achieve what you wanted via existing extension points (i.e. inheriting from ContentFinderByUrlNew, updating the logic to find content only with a matched domain, and registering your own implementation).

Could you let me know where you see the status of this issue is please?

[BenWhite27]

Hi @AndyButland

Sorry for the big writeup below, I think there's some improvements that can be made here, but as I don't know what is considered the designed behaviour inside the CMS, I'm unsure if this should be considered a bug or a feature request now. The reason I considered this a bug originally was because of a legacy setting called useDomainPrefixes. From old forum posts about this setting, it seemed to match my requirements, but I wasn't able to find a matching option in the latest versions.

Summary of original issues

It was really two different components related to routing

• URL Matching across different root nodes:
  At the time all root nodes were considered when trying to route a URL including paths that didn't have a root node with a matching domain.
  For example, say a visitor was browsing to site1.com/some-path/ this would match for site2.com/some-path/ if the path didn't exist under the site1.com root node.
• Unable to prevent Umbraco CMS delivering content for domains that weren't configured on root nodes.
  For example, if a visitor uses site3.com which has DNS pointing to my Umbraco Installation but isn't configured as a domain on a root node, Umbraco CMS will just serve content from the first root node it finds.

What I'm doing now

The URL matching issue seems to be resolved now after a combination of UrlProviderMode setting, Umbraco updates, and my workaround for domain matching below.

The domain matching is complicated as my site is on Umbraco Cloud.
What happened to me is that somehow the default cloud domain ....uksouth01.umbraco.io got indexed by google and started showing up in search results. As I have no control over the DNS on that domain it was quite difficult to get it removed and clean things up.
This is compounded by a documented troubleshooting tip on Umbraco Cloud (https://docs.umbraco.com/umbraco-cloud/go-live/manage-hostnames/rewrites-on-cloud#troubleshooting) where there's some kind of historical issue related to host headers that causes custom domains to stop working properly with IIS trying to serve content for a *.azurewebsites.net domain instead. This happened to my installation and the documented workaround (IIS config redirect) only works for a single domain. As I have multiple, I'm not aware of a way to rewrite the URL to the right one.

Domain matching workaround

I've currently setup a root node at the top of the content tree without any domains assigned to it. I use this root node to catch requests that aren't matched to a domain and for a home page I return a customised generic scheduled maintenance message, and for unknown paths I return a custom generic 404. Not ideal but okay.

What behaviour would I expect.

• If a root node has a matching domain for a request, only that node's content should be considered for the response.
• A setting should be available that enables strict domain matching, if a domain match isn't found the request could be dropped or an HTTP response that makes sense if that's more correct.

--

I hope that explains things Andy, as I mentioned I think there's room for improvement but unsure how this aligns with the intended behaviour.

Regards
Ben

[AndyButland]

Thanks for following up @BenWhite27, I appreciate the detailed write-up. I see the concern you are raising, though I was only able to partially replicate it.

I've had a stab at a solution to the part I could though, which is in the PR linked above. It'll have some review internally but if you'd like to have a look and feedback on if you think it'll meet the need you have raised, please do.

[BenWhite27]

Many thanks Andy, it may well be the case that some changes mean this isn't fully reproducible anymore.

I'll review the PR in the morning.

Much appreciated
Ben

[AndyButland]

Resolved via #19815 for 16.2.