Alcune delle applicazioni che realizziamo sono multi-tenant, ovvero hanno la capacità di offrire un servizio a vari clienti diversi da un'unica installazione.
Per identificare ed isolare i vari tenant (clienti) esistono varie soluzioni, come destinare a ciascuno di essi un particolare dominio di terzo livello:
nometenant.dominio.it altrotenant.dominio.it ...
Questo approccio non è poi così complesso da realizzare. Infatti, sia i maggiori provider di servizi DNS che l'eventuale certificato SSL che potremmo procurarci, supportano entrambi i domini wildcard, cioè scritture del tipo *.dominio.it. Con Windows 10 (e prossimamente su Windows Server 2016), anche il webserver IIS 10 permette di configurare un wildcard binding:

Con quest'unica e semplice configurazione prepariamo il sito a ricevere richieste da un qualsiasi dominio di terzo livello che ogni nostro cliente avrà scelto di usare.
Dall'applicazione ASP.NET, ovviamente, avremo la necessità di inviare query al database filtrando i risultati in base al nome del tenant corrente. Per ottenerlo, la cosa più immediata che possiamo fare è estrarlo dalla proprietà Request.Url.Host.
Tuttavia, per non avere dipendenze dall'oggetto Request e migliorare perciò la testabilità del nostro controller, è preferibile che il nome del tenant ci venga fornito dall'esterno, come argomento dell'action:
public ActionResult Index(string tenant) { // ... }
Affinché il Model Binder di ASP.NET MVC possa fornirci il valore corretto, andiamo a modificare in questo modo la route di default, che tipicamente troviamo nel file /App_Start/Route_Config.cs:
routes.MapRoute ( name: "Default", url: "{controller}/{action}/{id}", // Introduciamo un nuovo frammento chiamato "tenant"... defaults: new { tenant = "www", controller = "Home", action = "Index", id = UrlParameter.Optional }, // ...e lo vincoliamo ad un costraint constraints: new { tenant = new TenantRouteConstraint() } );
Qui fruttiamo un constraint al solo scopo di eseguire del codice all'arrivo di ogni richiesta. Ci occorre per recuperare il nome del tenant dall'hostname corrente ed aggiungerlo ai dati di routing. Andiamo perciò a creare nel progetto una classe TenantRouteConstraint che assolverà tale compito. Creaiamo il file di codice TenantRouteConstraint.cs in una cartella qualsiasi, come ad esempio in /Constraints.
// Implementiamo il metodo Match di IRouteConstraint public class TenantRouteConstraint : IRouteConstraint { public bool Match(HttpContextBase httpContext, Route route, string parameterName, RouteValueDictionary values, RouteDirection routeDirection) { if (routeDirection == RouteDirection.IncomingRequest) { // Otteniamo il nome del tenant con una espressione regolare var tenantNameRegex = new Regex(@"(.+)\..+\..+"); var match = tenantNameRegex.Match(httpContext.Request.Url.Host); if (match.Success) { // Se il valore è stato trovato, lo assegniamo al dizionario values[parameterName] = match.Groups[1].Value; } } return true; } }
A questo punto, visitando la nostra applicazione da un URL come http://aspitalia.dominio.it, riceveremo il valore aspitalia come nome del tenant.

Ora siamo liberi di usare questo valore per filtrare i risultati dal database (o scegliere un database appropriato) e mostrare al tenant solo i dati che lo riguardano.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Parallelizzare le chiamate HTTP con async/await e le Promise in JavaScript
Impostare il tema light o dark utilizzando i CSS
Creare un'istanza di Azure SQL Database tramite ARM
Utilizzare le Promise in Javascript - prima parte
Commentare una issue associata ad una pull request tramite un workflow di GitHub
.NET 7 Live Q&A
Produrre un inventario automatico di Azure Storage
Leggere i dati di configurazione di ASP.NET Core da Azure Key Vault
Monitorare metriche delle risorse Azure con Load Testing
Aggiungere le issue di più repository in una board in GitHub
Controllare lo stato di un servizio gRPC in ASP.NET Core tramite Health Check
Q# for Quantum Programming, an "only for the brave" session
I più letti di oggi
- ASP.NET MVC, Aree e Controller: risolvere le ambiguità
- Raggruppare i parametri di una minimal API in un singolo oggetto in ASP.NET Core
- Gestire tipi complessi in query string grazie a IParsable in ASP.NET Core 7.0
- Leggere e scrivere su cookie tramite Blazor
- Migliorare la scalabilità di ASP.NET Core 7 grazie all'output cache
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!