Domain Routing and resolving current tenant with ASP.NET MVC 6 / ASP.NET 5
Edit on GitHubSo you’re building a multi-tenant application. And just like many multi-tenant applications out there, the application will use a single (sub)domain per tenant and the application will use that to select the correct database connection, render the correct stylesheet and so on. Great! But how to do this with ASP.NET MVC 6?
A few years back, I wrote about ASP.NET MVC Domain Routing. It seems that post was more popular than I thought, as people have been asking me how to do this with the new ASP.NET MVC 6. In this blog post, I’ll do exactly that, as well as provide an alternative way of resolving the current tenant based on the current request URL.
Disclaimer: ASP.NET MVC 6 still evolves, and a big chance exists that this blog post is outdated when you are reading it. I’ve used the following dependencies to develop this against:
You’re on your own if you are using other dependencies.
Domain routing – what do we want to do?
The premise for domain routing is simple. Ideally, we want to be able to register a route like this:
The route would match any request that uses a hostname similar to *.localtest.me, where "*" is recognized as the current tenant and provided to controllers a a route value. And of course we can define the path route template as well, so we can recognize which controller and action to route into.
Domain routing – let’s do it!
Just like in my old post on ASP.NET MVC Domain Routing, we will be using the existing magic of ASP.NET routing and extend it a bit with what we need. In ASP.NET MVC 6, this means we’ll be creating a new IRouter implementation that encapsulates a TemplateRoute. Let’s call ours DomainTemplateRoute.
The DomainTemplateRoute has a similar constructor to MVC’s TemplateRoute, with one exception which is that we also want a domainTemplate parameter in which we can define the template that the host name should match. We will create a new TemplateRoute that’s held in a private field, so we can easily match the request path against that if the domain matches. This means we only need some logic to match the incoming domain, something which we need a TemplateMatcher for. This guy will parse {tenant}.localtest.me into a dictionary that contains the actual value of the tenant placeholder. Not deal, as the TemplateMatcher usually does its thing on a path, but since it treats a dot (.) as a separator we should be good there.
Having that infrastructure in place, we will need to build out the Task RouteAsync(RouteContext context) method that handles the routing. Simplified, it would look like this:
We match the hostname against our domain emplate. If it does not match, then the route does not match. If it does match, we call the inner TemplateRoute’s RouteAsync method and let that one handle the path template matching, constraints processing and so on. Lazy, but convenient!
We’re not there yet. We also want to be able to build URLs using the various HtmlHelpers that are around. If we pass it route data that is only needed for the domain part of the route, we want to strip it off the virtual path context so we don’t end up with URLs like /Home/About?tenant=tenant1 but instead with a normal /Home/About. Here’s a gist:
Fitting it all together, here’s the full DomainTemplateRoute class: https://gist.github.com/maartenba/77ca6f9cfef50efa96ec#file-domaintemplateroute-cs – The helpers for registering these routes are at https://gist.github.com/maartenba/77ca6f9cfef50efa96ec#file-domaintemplateroutebuilderextensions-cs
But there’s another approach!
One might say the only reason we would want domain routing is to know the current tenant in a multi-tenant application. This will often be the case, and there’s probably a more convenient method of doing this: by building a middleware. Ideally in our application startup, we want to add app.UseTenantResolver(); and that should ensure we always know the desired tenant for the current request. Let’s do this!
OWIN learned us that we can simply create our own request pipeline and decide which steps the current request is routed through. So if we create such step, a middleware, that sets the current tenant on the current request context, we’re good. And that’s exactly what this middleware does:
We check the current request, based on the request or one of its properties we create a Tenant instance and a TenantFeature instance and set it as a feature on the current HttpContext. And in our controllers we can now get the tenant by using that feature: Context.GetFeature<ITenantFeature>().
There you go, two ways of detecting tenants based on the incoming URL. The full source for both solutions is at https://gist.github.com/maartenba/77ca6f9cfef50efa96ec (requires some assembling).
This is an imported post. It was imported from my old blog using an automated tool and may contain formatting errors and/or broken images.
24 responses