Solucionar problemas do Serviço de Aplicativo no Application Gateway
Saiba como diagnosticar e resolver problemas que você pode encontrar quando o Serviço de Aplicativo do Azure é usado como um destino de back-end com o Gateway de Aplicativo do Azure.
Descrição geral
Neste artigo, você aprenderá a solucionar os seguintes problemas, conforme descrito com mais detalhes no Centro de arquitetura: Preservar o nome de host HTTP original entre um proxy reverso e seu aplicativo Web de back-end
- URLs absolutos incorretos
- URLs de redirecionamento incorretos
- a URL do serviço de aplicativo é exposta no navegador quando há um redirecionamento
- um exemplo disso: um fluxo de autenticação OIDC é quebrado devido a um redirecionamento com nome de host errado; isso inclui o uso de Autenticação e Autorização do Serviço de Aplicativo
- Cookies quebrados
- os cookies não são propagados entre o navegador e o Serviço de Aplicativo
- um exemplo disso: o domínio do cookie ARRAffinity do serviço de aplicativo é definido como o nome do host do serviço de aplicativo e está vinculado a "example.azurewebsites.net", em vez do host original. Como resultado, a afinidade de sessão é quebrada.
A causa básica para os sintomas acima é uma configuração que substitui o nome do host usado pelo Application Gateway para o Serviço de Aplicativo em um nome de host diferente, como é visto pelo navegador. Muitas vezes, o nome do host é substituído pelo domínio "azurewebsites.net" padrão do Serviço de Aplicativo.
Configuração de exemplo
Caso sua configuração corresponda a uma das duas situações abaixo, sua configuração está sujeita às instruções neste artigo:
- Escolher Nome do host de Endereço de back-end está ativado em Configurações HTTP
- A substituição por nome de domínio específico é definida com um valor diferente do que a solicitação do navegador tem
Causa
O Serviço de Aplicativo é um serviço multilocatário, portanto, ele usa o cabeçalho do host na solicitação para rotear a solicitação para o ponto de extremidade correto. O nome de domínio padrão dos Serviços de Aplicativo, *.azurewebsites.net (digamos, contoso.azurewebsites.net), é diferente do nome de domínio do gateway de aplicativo (digamos, contoso.com). O Serviço de Aplicativo de back-end está faltando o contexto necessário para gerar URLs de redirecionamento ou cookies que se alinham com o domínio, conforme visto pelo navegador.
Solução
A solução recomendada de produção é configurar o Application Gateway e o Serviço de Aplicativo para não substituir o nome do host. Siga as instruções para "Domínio personalizado (recomendado)" em Configurar o Serviço de Aplicativo com o Application Gateway
Considere apenas aplicar outra solução alternativa (como uma reescrita do cabeçalho Location conforme descrito abaixo) depois de avaliar as implicações conforme descrito no artigo: Preservar o nome de host HTTP original entre um proxy reverso e seu aplicativo Web de back-end. Essas implicações incluem o potencial de cookies vinculados ao domínio e de URLs absolutos fora do cabeçalho do local permanecerem quebrados.
Solução alternativa: reescreva o cabeçalho Location
Aviso
Esta configuração vem com limitações. Recomendamos examinar as implicações do uso de nomes de host diferentes entre o cliente e o Gateway de Aplicativo e entre o Aplicativo e o Serviço de Aplicativo no back-end. Para obter mais informações, consulte o artigo no Centro de arquitetura: Preservar o nome de host HTTP original entre um proxy reverso e seu aplicativo Web de back-end
Defina o nome do host no cabeçalho do local para o nome de domínio do gateway de aplicativo. Para fazer isso, crie uma regra de regravação com uma condição que avalie se o cabeçalho do local na resposta contém azurewebsites.net. Ele também deve executar uma ação para reescrever o cabeçalho do local para ter o nome de host do gateway de aplicativo. Para obter mais informações, consulte as instruções sobre como reescrever o cabeçalho do local.
Nota
O suporte à reconfiguração de cabeçalho HTTP só está disponível para o Standard_v2 e WAF_v2 SKU do Application Gateway. Recomendamos migrar para a v2 para Reescrita de Cabeçalho e outros recursos avançados disponíveis com a SKU v2.
Próximos passos
Se as etapas anteriores não resolverem o problema, abra um tíquete de suporte.