2004 (28)

Always have a host or URL prefix on the default Orchard tenant

The multi-tenancy feature in Orchard enables you to host multiple sites within the same Orchard instance. It’s not a a security feature, just a way to improve site density, and to enable you to save on hosting costs. Nevertheless, a request to a specific existing tenant should never be answered with a page from another tenant. Ever.

There is however a fallback mechanism that enables one tenant to handle all requests that weren’t identified by another tenant. While this could be considered useful in some scenarios, I’m hereby declaring it bad practice.

If for any reason a tenant fails to start, for example, requests to that tenant are going to fall back. Even if you were in a scenario where you considered fallback to be useful, this is an unexpected and positively undesirable result. It’s much better to fail with an error message or a 404 than to fail with a fallback to a different site than the one the client asked for.

So here is my recommendation:

Always have a host or URL prefix configured on all tenants, in particular the default tenant.

This way, no fallback will ever happen, and requests will only be handled by a tenant that recognizes its own host name.

Here is, for example, the new configuration of the default tenant on my hosted web sites:

Note that I have multiple hosts configured here, including the host that I use on my dev machine for local development, but the point here is to specify something on all tenants.

This is important.

4 Comments

Perhaps it's an idea to remove the fallback mechanism in its entirety? I also noticed that when one tenant is using an incorrect connectionstring, it fails even when the request comes in via another tenant. Perhaps it's related.

@Sipke: I agree: best practices should be the default. It is tricky however as this is a breaking change. I would argue that it's breaking undesirable behavior, but still. I'll bring it up at the meeting tomorrow.

This open another question (sorry I have many....): it could be intersting to share for different tenants a common part of their DB....for exemple Pricings in an ecommerce site. Price List are usually a very havy metal part of ecommerce after some months of run. Taking long time to open and necessitating synchronized updates.
Could this schema be constructed with Orchard: having a Common tenant.

@csadnt: this has been discussed many times, but never built. There are technical difficulties, such as the tenant databases being potentially separate, but now that we have WebAPI support we should revisit that. You will never be able to easily join with other tenants in a regular DB query, but common data is not out of the question. I'll bring it up at today's meeting.