Solucionar problemas do serviço de aplicativo no gateway de aplicativo

Saiba como diagnosticar e resolver problemas que podem ocorrer quando o Serviço de Aplicativo do Azure é usado como um destino de back-end com o Gateway de Aplicativo do Azure.

Visão geral

Neste artigo, você aprenderá a solucionar os seguintes problemas, conforme descrito 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

• URLs absolutas incorretas
• URLs de redirecionamento incorretas
  • a URL do serviço de aplicativo é exposta no navegador quando há um redirecionamento
  • um exemplo disso: um fluxo de autenticação OIDC é desfeito devido a um redirecionamento com nome de host incorreto; isso inclui o uso de autenticação e autorização do Serviço de Aplicativo
• Cookies desfeitos
  • 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 de 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 é desfeita.

A causa raiz dos sintomas acima é uma configuração que substitui o nome do host conforme usado pelo Gateway de Aplicativo para o Serviço de Aplicativo em um nome de host diferente como é visto pelo navegador. Geralmente, o nome do host é substituído para o domínio "azurewebsites.net" do Serviço de Aplicativo padrão.

Configurações de exemplo

Caso a configuração corresponda a uma das duas situações abaixo, ela estará sujeita às instruções neste artigo:

• Escolher nome de host do endereço de back-end está habilitado nas configurações de HTTP
• Substituir por um nome de domínio específico está definido como um valor diferente do que a solicitação do navegador tem

Causa

O serviço de aplicativo é um serviço multilocatário e, portanto, usa o cabeçalho de host na solicitação para roteá-la 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 não tem o contexto necessário para gerar os cookies ou as URLs de redirecionamento que se alinham com o domínio como visto pelo navegador.

Solução

A solução recomendada para produção é configurar Gateway de Aplicativo 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 Serviço de Aplicativo com Gateway de Aplicativo

Considere a aplicação de outra solução alternativa (como uma regeneração do cabeçalho do local, conforme descrito abaixo) depois de avaliar as implicações, conforme descrito no artigo: Preservar o nome do host HTTP original entre um proxy reverso e seu aplicativo Web de back-end. Essas implicações incluem o potencial para cookies vinculados a domínio e para URLs absolutas fora do cabeçalho de localização, para permanecerem desfeitos.

Solução alternativa: reescreva o cabeçalho de localização

Aviso

Essa configuração tem limitações. É recomendável revisar 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, leia o artigo no Centro de Arquitetura: Preservar o nome do host HTTP original entre um proxy reverso e seu aplicativo Web de back-end

Defina o nome do host no cabeçalho de localização como o nome de domínio do gateway de aplicativo. Para fazer isso, crie uma regra de reescrita com uma condição que seja avaliada se o cabeçalho de localização na resposta contiver azurewebsites.net. Ele também deve executar uma ação para reescrever o cabeçalho de localização para obter o nome de host do gateway de aplicativo. Para obter mais informações, consulte instruções sobre como reescrever o cabeçalho de localização.

Observação

O suporte à reescrita do cabeçalho HTTP só está disponível para Standard_v2 e WAF_V2 SKU do gateway de aplicativo. É recomendável migrar para v2 para Reescrita de Cabeçalho e outras funcionalidades avançadas que estão disponíveis com o SKU v2.

Próximas etapas

Se as etapas anteriores não resolverem o problema, abra um tíquete de suporte.