Hi,

If you have multiple sites inside Umbraco 8 you do not need multiple folders (everything goes into one site at c:\inetpub\wwwroot)

e.g.

You define the hostname for each site, in the 'Culture and Hostnames' options of a site (when you right click on its name)

this will tell Umbraco which site is which.

in azure, you need to then add the domains to the custom domains section of the web app

you will need to add custom DNS entries to do this bit - the azure docs should walk you through that.

this tells Azure that this one site is hosting all domains (this is analgous to the bindings in IIS)

I am running Umbraco v8 in a Azure VM. I can't see custom domains fields in the VM options. The VM has a public IP and a domain name assigned in Azure.

The Azure docs are totally unclear when explaining how to get sub domains and your own domain working with your website.

Please clarify. I am sure this will help a lot of people with the same queries.

I think (I don't use Azure VMs much haven't touched on in a while)

When you have a VM you point the domains to the IP address of the VM (via DNS A or CNAME record for the machine is probably a better option).

Then in IIS you add the bindings to the website so that the one site will serve all sites.

It could have, but it's already in my appsettings...

But of course thanks for the assistence! Any other suggestions maybe? :)

All the homenodes have their own hostname linked to it (all in the nodeName.localhost) style. Because this is real customer data I obfuscated most of the Nodes, but I'm sure you get the idea :)

The crossed out hostnames are the online ones. The English one has '/fritom/en' appended to it.

So the issue here is that fritom.localhost/Sanders shows the Sanders Hoomenode and all it's content. Same for all the others.

Since all nodes have English even fritom.localhost/en/Sanders returns the 'Sanders' content.

Just a note, eventhough I just registered here (again), I've been working with Umb7 for ~5 years already. Just had to make a new (personal) account because I switched jobs and couldn't recover my other account.

Hi Sjaak,

I think the Url providermode on the web.routing section is case sensitive.

Could you try urlProviderMode="Absolute"

Dave

Hey Dave,

tried it, but no change. Still able to open other homenodes using the wrong hostnames.

Thanks for the tip though! Keep 'em coming ;)

The reason I set up a nice and clean enviroment from scratch is exactly what you mentioned above.

There was 0 cache, all the hostnames are correct and there is nothing custom in code since I installed the base package, created the extra nodes, set the hostnames, added the bindings in IIS and that is it. Nothing more, nothing less.

It was only after that I started playing around to pinpoint the problem (as mentioned in the edits).

Not trying to be annoying here, but I'm trying my best to point out this is probably not a mistake from my side but an actual issue. (I'm not the only one with this multisite issue afaik)

Ahhhhhh - well spotted :)

Yep, seems like a bug to me. One for HQ to fix, or at-least showcase a way of stopping it happening.

I would guess that the template alias for the Micro Site node is micro-site? That's alternative templates kicking in, you can prevent that behavior by setting disableAlternativeTemplates="true" in your UmbracoSettings.config.

By default you can add a altTemplate querystring or append a template name to the current URL which will make Umbraco render the content on the current page with the template you requested, for example: http://mysite.com/about-us/?altTemplate=Home and http://mysite.com/about-us/Home would render the "About Us" page with a template with the alias Home. Setting this setting to true stops that behavior

It's not just the template.

It shows all the content (and the whole menu) belonging to it.

Which is part of the template?

Did you try setting disableAlternativeTemplates="true"?

Yes, I did. That's why I replied to that specific post ;)

Also http://home.localhost/?altTemplate=home2 Does give the home content as expected ;)

Edit: All the nodes use the same "Home" template

Are you saying disableAlternativeTemplates="true" does not disable alternative templates?

Alright, sorry, I don't really understand then from your screenshot what the problem is, this is what my setup looks like:

Edit: All the nodes use the same "Home" template

Ah, well that's a querying issue, there's a few tips in this thread already. So let's focus on what the actual problem is for you?

now try cork.nl/Test2

Does it show the Test2 Homepage?

or nul800sebastiaan.nl/Tester

and since we're on it

nul800sebastiaan.nl/Tester/about

or

cork.nl/Test2/about-us

And what happens when you do http://cork.nl/home2 ?

I think that is the issue that Sjaak is experiencing

Dave

now try cork.nl/Test2 Does it show the Test2 Homepage? or nul800sebastiaan.nl/Tester

Aha! The problem is that that does work, and it shouldn't, but there may be another config needing to be flipped.

and since we're on it nul800sebastiaan.nl/Tester/about or cork.nl/Test2/about-us

They don't work, which is expected.

Ah yeah I see, that /Test2/about-us was a bridge too far.

But yes. I would expect a 404 or something similar when doing

cork.nl/Test2 or nul800sebastiaan.nl/Tester

Since they are on different hostnames, and in my opnion (and opinions differ) hostnames are exclusively linked to that homenode and nodes below it.

To my defense it did work that way in Umb7 when using the correct settings (which seem to be removed/replaced) as mentioned in this post: https://our.umbraco.com/forum/getting-started/installing-umbraco/56192-Multisite-install-and-hostnames-in-IIS#

now try cork.nl/Test2 Does it show the Test2 Homepage? or nul800sebastiaan.nl/Tester

Wel.. ironically <add key="Umbraco.Core.HideTopLevelNodeFromPath" value="false" /> fixes this problem 🤷‍♂️

I am not grasping the code comments here at the moment but this "explains" what it does: https://github.com/umbraco/Umbraco-CMS/blob/v8/dev/src/Umbraco.Web/PublishedCache/NuCache/ContentCache.cs#L112

That seems to fix it!

I'll do some extensive testing (since the enviroment has 9 Homes) and will get back too you. But it looks promising!

Thanks!

WTF! That makes no sense but I just tried it and it works.

Not only the first one. I've been trying different possible options. In most cases all hostnames can be used to call any other homenode, and using that as a start all subpages as well.

Yeh, that definitely sound like routing. Checking into it for ours too, because we will need to not to happen on ours. An issue could arise with conflict with search engine indexing.

OK, I thought I remembered this, but in our Umbraco 7 site in Umbracosettings.config there is a section that calls out the unique domains,

<requestHandler>
    <!-- this will ensure that urls are unique when running with multiple root nodes -->
    <useDomainPrefixes>false</useDomainPrefixes>
    <!-- this will add a trailing slash (/) to urls when in directory url mode -->
    <addTrailingSlash>true</addTrailingSlash>   
  </requestHandler>

Domain prefixes. Mess with that setting and see if it works.

Just tried that - and no change - So guessing, this is no longer hooked up, is done via another method.

Well at least we found a point where to look in umb7 for a possible fix! I'm calling it a day, will check back in tomorrow!

That seems like a descent fix, but I'm not sure if that does it in my case.

The site is already live and I'm not sure if we are able to restructure everything. But at least we have something here :P

Agreed - especially if you have a lot of references to:

Model.Root()....

... It's going to be a headache, to re-write queries.

But I have seen Umbraco installs where this is the "usual setup" for Multilingual Sites, where the Model.Root is where all the "GLOBAL" settings are stored.

I prefer to have a separate node, for all that.

As always with "umbraco" - theres 99 ways to skin a cat.

Lets see if someone from the Core team notices this and decides to have a look at it. Although it is very quiet on their side, and I can't imagine this hasn't crossed anyones path yet ;)

I just wanted to reply to this one specifically: if you have any nodes displaying sensitive data then you should make sure that they're never accessible on a public URL. Just not advertising the URL is not an adequate defense, you need to limit public access to these URLs.