Multi Tenanting and Reverse Proxies - tooltwist/documentation GitHub Wiki

Multi-Tenanting is where there are effectively multiple websites run on a single server.

There are many variations, including:

  • an single eCommerce site supports many different stores.
  • a single Tomcat instance is serving multiple websites.
  • A single domain leads to more than one web server, based upon the URL.

The following diagrams show some of the options available.

Multi-Tenanting with a Reverse Proxy

With this approach, the first component of the URL is used to determine which back-end server should handle the request. For example all requests http://site.com/cow/... might be sent to server 1, and all requests matching http://site.com/chicken/... could be sent to server 2.

multi-tenanting-reverse-proxy

A basic mapping of the URL is performed on the way in, and a similar conversion of URLs is performed on all responses. For this to work effectively, a specific, unique prefix must be used by the back end site. This pattern will be replaced wherever it occurs in response, without any parsing or understanding of the content, so a name must be chosen that will never occur except in urls. For ToolTwist we use /ttsvr/.

An advantage and disadvantage of this approach is that multiple servers are used, although with Docker some of the disadvantages are removed. If you wish to have several tenants use the same server you can combine this approach with Multi-Tenanting by URL as described below.

The biggest advantage of this approach for us, is that a ToolTwist-developed site can be used for multi-tenanting in this way without changes.

See Multi-tenanting with a Reverse Proxy for details.

Multi-Tenanting by Domain Name

In this approach, multiple domain names lead to a single Tomcat instance. In a hosted shopping cart environment, this would allow the shopping cart software to determine the store ID from the domain name entered in the browser.

multi-tenanting-by-domain

In most cases a single ToolTwist webdesign project will be accessed, however basic functionality is provided to remap navpoints based upon the tenant. This can be used, for example to change the home page for a specific tenant.

While it is not recommended (are not properly tested), it is also possible to include multiple webdesign projects in the ttsvr webapp, and have the tenant map onto a specific project. Note however that there will be little or no isolation between the projects, posing a security risk if this function is used for anything more than basic static sites.

See Guide-to-using-MultiTenantInterceptor for details.

Multi-Tenanting by URL

This approach uses a URL naming convention similar to 'Multi-Tenanting with a Reverse proxy' as described above, however it uses a single Tomcat instance, and no reverse proxy.

multi-tenanting-by-url

As the request comes in, the site extracts the tenant part of the URL and saves it, where it can be used:

  1. Within the application, to determine the tenant id.
  2. To replace /ttsvr/ with the tenant name in URLs (and anywhere else it occurs) in a response.

See Guide-to-using-MultiTenantByUrl for details.