Configurações de HTTP do Gateway de Aplicativo
O gateway de aplicativo vai rotear o tráfego para os servidores de back-end usando a configuração que você especificar aqui. Depois de criar uma configuração de HTTP, você deve associá-la a pelo menos uma regra de roteamento de solicitação.
Afinidade baseada em cookie
O Gateway de Aplicativo do Azure usa cookies gerenciados pelo gateway para manter as sessões de usuário. Quando um usuário envia a primeira solicitação ao Gateway de Aplicativo, um cookie de afinidade é definido na resposta com um valor de hash que contém os detalhes da sessão, para que as solicitações subsequentes que tenham o cookie de afinidade sejam roteadas para o mesmo servidor de back-end para manter a adesão.
Esse recurso é útil para manter uma sessão de usuário no mesmo servidor e quando o estado de sessão é salvo localmente no servidor para uma sessão de usuário. Esse recurso não poderá ser usado se o aplicativo não puder lidar com a afinidade baseada em cookie. Para usá-lo, certifique-se de que os clientes dão suporte a cookies.
Observação
Algumas verificações de vulnerabilidade podem sinalizar o cookie de afinidade do Gateway de Aplicativo porque os sinalizadores Secure ou HttpOnly não estão definidos. Tais verificações não consideram que os dados no cookie são gerados usando um hash único. O cookie não contém nenhuma informação do usuário e é usado puramente para roteamento.
A atualização do navegador Chromiumv80 introduziu a exigência de que os cookies de HTTP sem o atributo SameSite sejam tratados como SameSite=Lax. Para solicitações de CORS (Compartilhamento de Recursos entre Origens), se o cookie tiver que ser enviado em um contexto de terceiros, ele precisa usar os atributos SameSite = None; Secure e deve ser enviado somente por HTTPS. Em um cenário somente HTTP, o navegador não vai enviar os cookies no contexto de terceiros. O objetivo dessa atualização do Chrome é aprimorar a segurança e evitar ataques CSRF (Solicitação Intersite Forjada).
Para dar suporte a essa alteração, a partir de 17 de fevereiro de 2020, o Gateway de Aplicativo (todos os tipos de SKU) vai injetar outro cookie chamado ApplicationGatewayAffinityCORS além do cookie ApplicationGatewayAffinity existente. O cookie ApplicationGatewayAffinityCORS tem mais dois atributos adicionados (“SameSite=None; Secure”), para que as sessões temporárias também sejam mantidas para as solicitações entre origens.
Observe que o nome do cookie de afinidade padrão é ApplicationGatewayAffinity e pode ser alterado. Caso você esteja usando um nome de cookie de afinidade personalizado, um cookie adicional é adicionado com o sufixo CORS. Por exemplo, o CustomCookieNameCORS.
Observação
Se o atributo SameSite = None estiver definido, é obrigatório que o cookie também contenha o sinalizador de Segurança e seja enviado via HTTPS. Se a afinidade de sessão for necessária em CORS, você deve migrar sua carga de trabalho para HTTPS. Consulte o descarregamento de TLS e a documentação de TLS de Ponta a Ponta para o Gateway de Aplicativo aqui – Visão geral, Configurar um gateway de aplicativo com terminação TLS usando o portal do Azure, Configurar TLS de Ponta a Ponta usando o Gateway de Aplicativo com o portal.
Descarregamento de conexão
O esvaziamento de conexões ajuda você a remover membros de um pool de back-end durante as atualizações de serviço planejadas. Aplica-se a instâncias de back-end que são
- explicitamente removido do pool de back-end,
- removido durante operações de redução horizontal ou
- relatadas como não íntegras pelas investigações de integridade.
É possível aplicar essa configuração a todos os membros de um pool de back-end habilitando o esvaziamento de conexões na configuração de back-end. Ele garante que todas as instâncias de cancelamento de registro em um pool de back-end não recebam novas solicitações/conexões, mantendo as conexões existentes até o valor de tempo limite configurado. Isso também é verdadeiro para conexões WebSocket.
| Tipo de Configuração | Valor |
|---|---|
| Valor padrão quando o esvaziamento de conexões não está habilitado na configuração de back-end | 30 segundos |
| Valor padrão quando o esvaziamento de conexões não está habilitado na configuração de back-end | Um a 3600 segundos |
A única exceção são as solicitações limitadas às instâncias de cancelamento de registro devido à afinidade de sessão gerenciada por gateway, que vão continuar a ser encaminhadas para as instâncias de cancelamento de registro.
Protocolo
O Gateway de Aplicativo dá suporte a HTTP e a HTTPS para solicitações de roteamento para os servidores de back-end. Se você escolher HTTP, o tráfego para os servidores de back-end não é criptografado. Se não for possível usar a comunicação não criptografada, escolha HTTPS.
Essa configuração combinada com HTTPS no ouvinte dá suporte ao TLS de ponta a ponta. Isso permite que você transmita os dados confidenciais criptografados com segurança para o back-end. Cada servidor no pool de back-end com TLS de ponta a ponta habilitado deve ser configurado com um certificado para permitir uma comunicação segura.
Porta
Essa configuração especifica a porta em que os servidores de back-end escutam o tráfego do gateway de aplicativo. Você pode configurar portas que variam entre 1 e 65535.
Certificado raiz confiável
Se você selecionar HTTPS como o protocolo de back-end, o Gateway de Aplicativo exigirá um certificado raiz confiável para confiar no pool de back-end do SSL de ponta a ponta. Por padrão, a opção Usar certificado de Autoridade de Certificação conhecida é definida como Não. Se você planeja usar um certificado autoassinado ou um certificado assinado por uma Autoridade de Certificação interna, forneça ao Gateway de Aplicativo o certificado público correspondente que o pool de back-end usará. Esse certificado deve ser carregado diretamente no Gateway de Aplicativo no formato .CER.
Se você planeja usar um certificado no pool de back-end assinado por uma Autoridade de Certificação pública confiável, defina a opção Usar certificado de Autoridade de Certificação conhecida como Sim e ignorar o carregamento de um certificado público.
Tempo limite da solicitação
Essa configuração é o número de segundos que o gateway de aplicativo aguarda para receber uma resposta do servidor de back-end.
Substituir caminho de back-end
Essa configuração permite a configuração de um caminho de encaminhamento personalizado opcional para ser usado quando a solicitação for encaminhada para o back-end. Qualquer parte do caminho de entrada que corresponda ao caminho personalizado no campo substituir caminho de back-end é copiada para o caminho encaminhado. A seguinte tabela mostra como esse recurso funciona:
Quando a configuração de HTTP é anexada a uma regra básica de roteamento de solicitação:
Solicitação original Substituir caminho de back-end Solicitação encaminhada para o back-end /home/ /override/ /override/home/ /home/secondhome/ /override/ /override/home/secondhome/ Quando a configuração de HTTP é anexada a uma regra de roteamento de solicitação baseada no caminho:
Solicitação original Regra do caminho Substituir caminho de back-end Solicitação encaminhada para o 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/
Usar investigação personalizada
Essa configuração associa a investigação personalizada a uma configuração de HTTP. Somente uma investigação personalizada pode ser associada a uma configuração de HTTP. Se você não associar explicitamente uma investigação personalizada, a investigação padrão vai ser usada para monitorar a integridade do back-end. Recomendamos a criação de uma investigação personalizada para um maior controle do monitoramento de integridade dos back-ends.
Observação
A investigação personalizada não vai monitorar a integridade do pool de back-end, a menos que a configuração de HTTP correspondente esteja explicitamente associada a um ouvinte.
Configurando o nome do host
Gateway de Aplicativo permite que a conexão estabelecida com o back-end use um nome de host diferente daquele usado pelo cliente para se conectar ao Gateway de Aplicativo. Embora essa configuração possa ser útil em alguns casos, substituir o nome do host para ser diferente entre o cliente e o gateway de aplicativo e entre o gateway de aplicativo e o destino de back-end deve ser feito com cuidado.
Em produção, é recomendável manter o nome do host usado pelo cliente em direção ao gateway de aplicativo como o mesmo nome de host usado pelo gateway de aplicativo para o destino de back-end. Isso evita possíveis problemas com URLs absolutas, URLs de redirecionamento e cookies associados ao host.
Antes de configurar Gateway de Aplicativo que se desvie disso, examine as implicações dessa configuração, conforme discutido em mais detalhes no Centro de Arquitetura: preservar o nome de host HTTP original entre um proxy reverso e seu aplicativo Web de back-end
Há dois aspectos de uma configuração HTTP que influenciam o cabeçalho HTTP Host usado pelo Gateway de Aplicativo para se conectar ao back-end:
- "Escolher o nome de host do endereço de back-end"
- "Substituir o nome do host"
Escolher o nome de host do endereço de back-end
Essa funcionalidade define dinamicamente o cabeçalho de host na solicitação para o nome do host do pool de back-end. Ele usa um endereço IP ou um FQDN.
Esse recurso ajuda quando o nome de domínio do back-end é diferente do nome DNS do gateway de aplicativo e o back-end depende de um cabeçalho de host específico para resolver para o ponto de extremidade correto.
Um exemplo são os serviços de vários locatários como o back-end. Um serviço de aplicativo é um serviço de vários locatários que usa um espaço compartilhado com um endereço IP. Portanto, um serviço de aplicativo só pode ser acessado por meio dos nomes de host que são definidos nas configurações do domínio personalizado.
Por padrão, o nome de domínio personalizado é example.azurewebsites.net. Para acessar o serviço de aplicativo usando um gateway de aplicativo por meio do nome do host que não está explicitamente registrado no serviço de aplicativo ou por meio do FQDN do gateway de aplicativo, substitua o nome do host na solicitação original pelo nome do host do serviço de aplicativo. Para fazer isso, habilite a configuração escolher nome do host do endereço de back-end.
Para um domínio personalizado cujo nome DNS personalizado existente está mapeado para o serviço de aplicativo, a configuração recomendada não é habilitar o nome de host de escolha do endereço de back-end.
Observação
Essa configuração não é necessária para um Ambiente do Serviço de Aplicativo, que é uma implantação dedicada.
Substituir o nome do host
Essa funcionalidade substitui o cabeçalho de host na solicitação de entrada no gateway de aplicativo pelo nome do host que você deseja especificar.
Por exemplo, se for especificado www.contoso.com na configuração do Nome do host, a solicitação original *https://appgw.eastus.cloudapp.azure.com/path1 é alterada para *https://www.contoso.com/path1 quando a solicitação é encaminhada para o servidor de back-end.