Come abbiamo visto nello script precedente (https://www.aspitalia.com/script/1427/Impostare-Forward-Header-Sito-ASP.NET-Core-Reverse-Proxy.aspx), l'utilizzo di un reverse proxy con ASP.NET Core può necessitare di impostare le forwarded header per ottenere informazioni sulla richiesta originaria.

Se il nostro sito web è servito tramite Azure Application Gateway, esistono alcune ulteriori particolarità di cui dobbiamo essere al corrente.

Innanzi tutto, l'header utilizzato per il forwarded host non è quello standard, ma X-ORIGINAL-HOST:

public static void Main(string[] args)
{
    var builder = WebApplication.CreateBuilder(args);

    // ... altro codice qui ...
    builder.Services.Configure<ForwardedHeadersOptions>(options =>
    {
        options.ForwardedHeaders =
            ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto |
            ForwardedHeaders.XForwardedHost;

        options.ForwardedHostHeaderName = "X-ORIGINAL-HOST";

        options.KnownNetworks.Clear();
        options.KnownProxies.Clear();
    });

    var app = builder.Build();

    app.UseForwardedHeaders();

    // ... altro codice qui ...

    app.Run();
}

In secondo luogo, come possiamo notare, abbiamo dovuto svuotare la lista dei KnownProxies e KnownNetwork. Esse contengono gli IP (o i range di IP) dai quali ASP.NET Core accettarà le forwarded header. Nel caso di Application Gateway, l'IP sarà appartenente alla virtual network interna. Effettuando il Clear delle due liste, stiamo in pratica disabilitando questo controllo lato ASP.NET Core.

Ovviamente si tratta di un possibile buco di sicurezza, che dobbiamo mitigare restringendo il possibile chiamante al nostro servizio, per esempio implementando una regola sul firewall. Se stiamo facendo girare il nostro sito su App Service, possiamo sfruttare una restrizione basata su Service Endpoint, in maniera simile a come descritto in questo nostro precedente script:
https://www.cloudnativeitalia.com/script/229/Filtrare-Chiamate-HTTP-App-Service-Base-Servizio-Azure.aspx