Configurazione delle impostazioni HTTP del gateway applicazione
Il gateway applicazione instrada il traffico ai server back-end usando la configurazione specificata qui. Dopo aver creato un'impostazione HTTP, è necessario associarla a una o più regole di routing delle richieste.
Affinità basata sui cookie
Il gateway applicazione di Azure usa i cookie gestiti dal gateway per gestire le sessioni utente. Quando un utente invia la prima richiesta a gateway applicazione, imposta un cookie di affinità nella risposta con un valore hash che contiene i dettagli della sessione, in modo che le richieste successive che trasportano il cookie di affinità vengano instradate allo stesso server back-end per mantenere la persistenza.
Questa funzionalità è utile quando si desidera mantenere una sessione utente nello stesso server e quando lo stato della sessione viene salvato localmente nel server per una sessione utente. Se l'applicazione non è in grado di gestire l'affinità basata su cookie, non è possibile usare questa funzionalità. Per usarla, assicurarsi che i client supportino i cookie.
Nota
Alcune analisi di vulnerabilità possono contrassegnare il cookie di affinità del gateway applicazione perché i flag Secure o HttpOnly non sono impostati. Queste analisi non prendono in considerazione che i dati nel cookie vengono generati usando un hash unidirezionale. Il cookie non contiene informazioni sull'utente e viene usato esclusivamente per il routing.
L'aggiornamento del browser Chromium v80 ha portato un mandato in cui i cookie HTTP senza attributo SameSite devono essere trattati come SameSite=Lax. Per le richieste CORS (condivisione di risorse tra le origini), se il cookie deve essere inviato in un contesto di terze parti, deve usare gli attributi SameSite=None; Secure e deve essere inviato solo tramite HTTPS. In caso contrario, in uno scenario solo HTTP, il browser non invia i cookie nel contesto di terze parti. L'obiettivo di questo aggiornamento da Chrome è quello di migliorare la sicurezza e di evitare attacchi CSRF (Cross-Site Request Forgery).
Per supportare questa modifica, a partire dal 17 febbraio 2020, il gateway applicazione (tutti i tipi di SKU) inserirà un altro cookie denominato ApplicationGatewayAffinityCORS oltre al cookie ApplicationGatewayAffinityesistente. Il cookie ApplicationGatewayAffinityCORS contiene altri due attributi aggiunti ("SameSite=None; Proteggere") in modo che le sessioni permanenti vengano mantenute anche per le richieste tra le origini.
Si noti che il nome predefinito del cookie di affinità è ApplicationGatewayAffinity ed è possibile modificarlo. Se nella topologia di rete si distribuiscono più gateway applicazione in linea, è necessario impostare nomi di cookie univoci per ogni risorsa. Se si usa un nome di cookie di affinità personalizzato, viene aggiunto un cookie aggiuntivo con CORS come suffisso. Ad esempio: CustomCookieNameCORS.
Nota
Se l'attributo SameSite=None è impostato, è obbligatorio che il cookie contenga anche il flag Secure, e deve essere inviato tramite HTTPS. Se l'affinità di sessione è necessaria su CORS, è necessario eseguire la migrazione del carico di lavoro a HTTPS. Vedere la documentazione di TLS offload e TLS end-to-end per il gateway applicazione qui - Panoramica, Configurare un gateway applicazione con terminazione TLS con il portale di Azure,Configurare TLS end-to-end usando il gateway applicazione con il portale.
Svuotamento della connessione
Lo svuotamento delle connessioni consente di rimuovere normalmente i membri del pool back-end durante gli aggiornamenti pianificati del servizio. Si applica alle istanze back-end che sono
- rimosso in modo esplicito dal pool back-end o
- segnalate come non integre dai probe di integrità.
È possibile applicare questa impostazione a tutti i membri del pool back-end abilitando lo svuotamento delle connessioni nell'impostazione back-end. Garantisce che tutte le istanze di registrazione in un pool back-end non ricevano nuove richieste/connessioni mantenendo le connessioni esistenti fino al valore di timeout configurato. Questo vale anche per le connessioni WebSocket.
| Tipo configurazione | Valore |
|---|---|
| Valore predefinito quando lo svuotamento della connessione non è abilitato nell'impostazione back-end | 30 secondi |
| Valore definito dall'utente quando lo svuotamento della connessione è abilitato nell'impostazione back-end | Da 1 a 3600 secondi |
L'unica eccezione è costituita dalle richieste associate per la deregistrazione delle istanze a causa dell'affinità di sessione gestita dal gateway. Queste richieste continuano a essere inoltrate alle istanze di deregistrazione.
Protocollo
Il gateway applicazione supporta sia HTTP che HTTPS per il routing delle richieste ai server back-end. Se si sceglie HTTP, il traffico verso i server back-end non è crittografato. Se la comunicazione non crittografata non è accettabile, scegliere HTTPS.
Questa impostazione combinata con HTTPS nel listener supporta TLS end-to-end. In questo modo è possibile trasmettere in modo sicuro i dati sensibili crittografati al back-end. Ogni server back-end nel pool back-end con TLS end-to-end abilitato deve essere configurato con un certificato per consentire la comunicazione sicura.
Porta
Questa impostazione specifica la porta in cui i server back-end sono in ascolto del traffico dal gateway applicazione. È possibile configurare porte comprese tra 1 e 65535.
Certificato radice trusted
Se si seleziona HTTPS come protocollo back-end, il gateway applicazione richiede un certificato radice attendibile per considerare attendibile il pool back-end per SSL end-to-end. Per impostazione predefinita, l'opzione Usa un certificato CA noto è impostata su No. Se si prevede di usare un certificato autofirmato o un certificato firmato da un'autorità di certificazione interna, è necessario fornire il gateway applicazione il certificato pubblico corrispondente usato dal pool back-end. Questo certificato deve essere caricato direttamente nel gateway applicazione in . Formato CER.
Se si prevede di usare un certificato nel pool back-end firmato da un'autorità di certificazione pubblica attendibile, è possibile impostare l'opzione Usa certificato CA noto su Sì e ignorare il caricamento di un certificato pubblico.
Timeout richiesta
Questa impostazione è il numero di secondi durante i quali il gateway applicazione resta in attesa di ricevere una risposta dal server back-end.
Sostituisci percorso back-end
Questa impostazione consente di configurare un percorso di inoltro personalizzato facoltativo da usare quando la richiesta viene inoltrata al back-end. Qualsiasi parte del percorso in ingresso corrispondente al percorso personalizzato nel campo percorso back-end di override viene copiata nel percorso inoltrato. La tabella seguente illustra il funzionamento di questa funzionalità:
Quando l'impostazione HTTP è collegata a una regola di routing delle richieste di base:
Richiesta originale Sostituisci percorso back-end Richiesta inoltrata al back-end /home/ /override/ /override/home/ /home/secondhome/ /override/ /override/home/secondhome/ Quando l'impostazione HTTP è collegata a una regola di routing delle richieste basata sul percorso:
Richiesta originale Regola percorso Sostituisci percorso back-end Richiesta inoltrata al back-end /pathrule/home/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /home/ /pathrule* /override/ /override/home/ /home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /override/ /override/ /pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/ /pathrule/ /pathrule/ /override/ /override/
Usa probe personalizzato
Questa impostazione associa un probe personalizzato a un'impostazione HTTP. È possibile associare un solo probe personalizzato a un'impostazione HTTP. Se non si associa in modo esplicito un probe personalizzato, il probe predefinito viene usato per monitorare l'integrità del back-end. È consigliabile creare un probe personalizzato per un maggiore controllo sull'integrità dei back-end.
Nota
Il probe personalizzato non monitora l'integrità del pool back-end, a meno che l'impostazione HTTP corrispondente non sia associata in modo esplicito a un listener.
Configurazione del nome host
Il gateway applicazione consente alla connessione stabilita al back-end di usare un nome host diverso da quello usato dal client per connettersi al gateway applicazione. Anche se questa configurazione può essere utile in alcuni casi, prestare attenzione quando si esegue l'override del nome host in modo che sia diverso tra il gateway applicazione e il client rispetto alla destinazione back-end.
Nell'ambiente di produzione, è consigliabile mantenere il nome host usato dal client verso il gateway applicazione come lo stesso nome host usato dal gateway applicazione alla destinazione back-end. In questo modo si evitano potenziali problemi con URL assoluti, URL di reindirizzamento e cookie associati a host.
Prima di configurare il gateway applicazione che devia da questo aspetto, esaminare le implicazioni di tale configurazione, come descritto in dettaglio in Centro architetture: Mantenere il nome host HTTP originale tra un proxy inverso e l'applicazione Web back-end
Esistono due aspetti di un'impostazione HTTP che influiscono sull'intestazione HTTP Host usata dal gateway applicazione per connettersi al back-end:
- “Nome host di selezione dall'indirizzo back-end”
- “Override del nome host”
Selezionare nome host dall'indirizzo back-end
Questa funzionalità imposta dinamicamente l'intestazione host nella richiesta sul nome host del pool back-end. Usa un indirizzo IP o un nome di dominio completo.
Questa funzionalità è utile quando il nome di dominio del back-end è diverso dal nome DNS del gateway applicazione e il back-end si basa su un'intestazione host specifica per risolvere l'endpoint corretto.
Un caso di esempio è costituito dai servizi multi-tenant come back-end. Un servizio app è un servizio multi-tenant che usa uno spazio condiviso con un singolo indirizzo IP. È quindi possibile accedere a un servizio app solo tramite i nomi host configurati nelle impostazioni di dominio personalizzate.
Per impostazione predefinita, il nome di dominio personalizzato è example.azurewebsites.net. Per accedere al servizio app usando un gateway applicazione tramite un nome host non registrato in modo esplicito nel servizio app o tramite il nome di dominio completo del gateway applicazione, è possibile eseguire l'override del nome host nella richiesta originale al nome host del servizio app. A tale scopo, abilitare l'impostazione seleziona nome host dall'indirizzo back-end.
Per un dominio personalizzato il cui nome DNS personalizzato esistente è mappato al servizio app, la configurazione consigliata non consiste nell'abilitare il nome host di selezione dall'indirizzo back-end.
Nota
Questa impostazione non è necessaria per l'ambiente del servizio app, ovvero una distribuzione dedicata.
Override nome host
Questa funzionalità sostituisce l'intestazione host nella richiesta in ingresso nel gateway applicazione con il nome host specificato.
Ad esempio, se www.contoso.com viene specificato nell'impostazione Nome host, la richiesta originale *https://appgw.eastus.cloudapp.azure.com/path1 viene modificata in *https://www.contoso.com/path1 quando la richiesta viene inoltrata al server back-end.