Compartilhar via

Cenários e configurações do mecanismo de regras do Azure Front Door

O mecanismo de regras do Azure Front Door permite que os usuários personalizem facilmente a lógica de processamento e roteamento na periferia do Azure Front Door, configurando pares de condição de correspondência e ação.

Você pode definir várias ações de regra com base na combinação de 19 condições de correspondência com suporte de solicitações recebidas. Essas regras permitem que você:

  1. Gerenciar a política de cache dinamicamente

  2. Encaminhar solicitações para diferentes origens ou versões

  3. Modifique os cabeçalhos de solicitação ou resposta para ocultar informações confidenciais ou para transmitir informações importantes através dos cabeçalhos. Por exemplo, implementar cabeçalhos de segurança para evitar vulnerabilidades baseadas no navegador, como:

    • HTTP strict-transport-security (HSTS)
    • Proteção X-XSS
    • Política de segurança de conteúdo
    • Opções de quadro X
    • Cabeçalhos Access-Control-Allow-Origin para cenários de compartilhamento de recursos entre origens (CORS). Os atributos baseados em segurança também podem ser definidos com cookies.

  4. Reescrever caminhos de URL ou solicitações de redirecionamento para novos destinos

  5. Habilite cenários complexos usando variáveis regex e de servidor: capture valores dinâmicos de solicitações ou respostas de entrada e combine-os com cadeias de caracteres estáticas ou outras variáveis.

Este artigo aborda casos de uso comuns compatíveis com o mecanismo de regras do Azure Front Door e fornece exemplos de configuração detalhados para atender a vários requisitos técnicos e comerciais.

Cenário 1: redirecionar usando cadeia de caracteres de consulta, segmentos de caminho de URL ou capturas de nome de host recebidas

O gerenciamento de redirecionamentos é fundamental para a SEO (otimização do mecanismo de pesquisa), a experiência do usuário e o funcionamento adequado de um site. As variáveis de servidor e mecanismo de regras do Azure Front Door permitem gerenciar redirecionamentos em lotes com eficiência com base em vários parâmetros.

  • Redirecionamento com base em parâmetros de cadeia de caracteres de consulta: Você pode redirecionar solicitações usando campos de consulta da URL de entrada capturando o valor de uma chave de cadeia de caracteres de consulta específica no formato {http_req_arg_<key>}.

    Por exemplo, extraia o valor da chave de cdpb consulta de uma URL de entrada: https://example.mydomain.com/testcontainer/123.zip?sig=fffff&cdpb=teststorageaccount e use-a para configurar o host de destino na URL de saída: https://teststorageaccount.blob.core.windows.net/testcontainer/123.zip?sig=fffff&cdpb=teststorageaccount.

    Essa abordagem permite redirecionamentos dinâmicos sem precisar criar uma regra separada para cada cdpb valor, reduzindo significativamente o número de regras necessárias.

    Captura de tela que mostra como usar a cadeia de caracteres de consulta para redirecionar a URL.

  • Redirecionamento com base em segmentos de caminho de URL de comprimento fixo: Você pode redirecionar solicitações para origens diferentes com base no segmento de caminho de URL de comprimento fixo capturando os segmentos de URL usando {variable:offset:length}. Para obter mais informações, consulte o formato de variável do servidor.

    Por exemplo, considere um cenário em que a ID do locatário é inserida no segmento de URL e tem sempre seis caracteres, como: https://api.contoso.com/{tenantId}/xyz. Para extrair {tenantId} da URL e decidir o redirecionamento correto a ser usado no formato de tenantId.backend.com/xyz.

    Esta abordagem elimina a necessidade de criar uma regra separada para cada ID de inquilino, permitindo lidar com o roteamento dinâmico com um número menor de regras.

    Captura de tela que mostra como usar o segmento de caminho de comprimento fixo para redirecionar a URL.

  • Redirecionar com base em segmentos de caminho de URL de comprimento dinâmico: Quando o segmento de caminho de URL tem um comprimento dinâmico, você pode extraí-lo usando o {url_path:seg#}. Para obter mais informações, consulte o formato de variável do servidor.

    Por exemplo, se um ID de locatário ou local estiver inseridos no segmento de URL, como: https://api.contoso.com/{tenantId}/xyz, você poderá extrair {tenantId} da URL e decidir o redirecionamento correto no formato de tenantId.backend.com/xyz com a variável de servidor {url_path:seg0}.backend.com no host de destino de redirecionamento.

    Esse método evita a criação de regras separadas para cada ID de locatário, permitindo uma configuração mais eficiente.

    Não aplicável

  • Redirecionar com base em parte do nome do host de entrada: Você pode redirecionar solicitações para origens diferentes extraindo parte do nome do host de entrada.

    Por exemplo, você pode capturar tenantName de https://[tenantName].poc.contoso.com/GB para redirecionar a solicitação para s1.example.com/Buyer/Main?realm=[tenantName]&examplename=example1 usando o deslocamento e o comprimento na variável de servidor no formato de {hostname:0:-16}. Para obter mais informações, consulte o formato de variável do servidor.

    Captura de tela que mostra como usar o nome do host de entrada para redirecionar a URL.

Cenário 2: Preencher ou modificar um cabeçalho de resposta com base em um valor de cabeçalho de solicitação

Em alguns cenários, talvez seja necessário preencher ou modificar um cabeçalho de resposta com base em um valor de cabeçalho de solicitação.

Por exemplo, você pode adicionar o cabeçalho CORS quando necessário para servir scripts em múltiplas origens a partir do mesmo domínio CDN. Além disso, a resposta deve conter o mesmo FQDN no cabeçalho Access-Control-Allow-Origin que o cabeçalho de origem da solicitação, em vez de usar um curinga (*) que permita todos os domínios, de modo a melhorar a segurança. Você pode obtê-lo usando a variável de {http_req_header_Origin} servidor para definir o cabeçalho de resposta.

Captura de tela que mostra como modificar um cabeçalho de resposta com base em um valor de cabeçalho de solicitação.

Cenário 3: renomear um cabeçalho de resposta para um específico da marca

Você pode renomear um cabeçalho de resposta gerado por um provedor de nuvem adicionando um novo cabeçalho de resposta personalizado e excluindo o original.

Por exemplo, você pode substituir o cabeçalho X-Azure-Backend-ID de resposta por um cabeçalho X-Contoso-Scale-IDespecífico da marca.

Captura de tela que mostra como renomear um cabeçalho de resposta para um específico da marca.

Cenário 4: Teste A/B (experimentação)

Dividir o tráfego de entrada em dois grupos de origem pode ser útil em testes A/B, implantações sem interrupção ou balanceamento de carga sem lógica de back-end complexa.

Por exemplo, você pode dividir o tráfego de entrada com base no número da porta do cliente. Uma regra pode corresponder às portas do cliente que terminam em 1, 3, 5, 7 ou 9 e encaminhar essas solicitações para um grupo de origem de experimento. Todo o tráfego restante continua para o grupo de origem padrão conforme as configurações de rota. O regex anterior é apenas um exemplo. Você pode explorar e testar suas próprias expressões usando ferramentas como regex101.

Observação

Como as portas do cliente são aleatórias, esse método normalmente resulta em uma divisão de tráfego aproximada de 50/50. No entanto, a presença de proxies ou balanceadores de carga entre clientes e o Front Door pode afetar essa suposição devido a fatores como reutilização de conexão ou reescrita de porta de origem. Use logs ou métricas para validar o comportamento real em seu ambiente.

Captura de tela que mostra como dividir o tráfego de entrada em dois grupos de origem.

Cenário 5: Redirecionar com a modificação do caminho de URL e preservar a funcionalidade

Em alguns cenários, talvez seja necessário adicionar novos segmentos ou remover alguns segmentos, preservando o restante do caminho da URL.

Por exemplo, se você quiser redirecionar https://domain.com/seg0/seg1/seg2/seg3 para https://example.com/seg0/insert/seg2/seg3. Neste cenário, você substitui {seg1} do caminho da URL por /insert/, preservando o restante do caminho da URL. O Azure Front Door alcança o redirecionamento desejado ao combinar valores extraídos de variáveis de servidor (segmentos de URL) com o segmento de cadeia de caracteres estática /insert/. Você pode usar o campo de comprimento do segmento de URL Int32.Max (2147483647) para manter todos os segmentos de seg2 a segn. Para obter mais informações, consulte o formato de variável do servidor.

Observação

Configuração semelhante pode ser feita para a ação de reescrita de URL inserindo o padrão de origem como / e o destino como /{url_path:seg0}/insert/{url_path:seg2:2147483647} para a ação de redirecionamento, conforme mostrado no exemplo a seguir do portal.

Captura de tela que mostra como redirecionar com a modificação do caminho da URL preservando parte do caminho da URL.

Cenário 6: Redirecionar removendo partes fixas de um caminho de URL

Você pode remover segmentos fixos de tamanho conhecido de um caminho de URL, como códigos de país (nós) ou localidades (en-us), preservando o restante do caminho da URL.

Por exemplo, se você quiser redirecionar https://domain.com/us/seg1/seg2/seg3/https://example.com/seg1/seg2/seg3/, será necessário remover o código /us/ do país e manter o restante do caminho da URL inalterado.

Para fazer isso, use {variable:offset} , que inclui a variável de servidor após um deslocamento específico, até o final da variável. Para obter mais informações, consulte o formato de variável do servidor.

Observação

Configuração semelhante pode ser feita para a ação de reescrita de URL inserindo o padrão de origem como / e o destino como /“{url_path:3} para a ação de redirecionamento, conforme mostrado no exemplo a seguir do portal.

Captura de tela que mostra como redirecionar removendo partes fixas de um caminho de URL.

Cenário 7: regravação de URL removendo um ou mais segmentos de caminho de URL

Você pode remover um ou mais segmentos de um caminho de URL, como códigos de país (nós) ou localidades (en-us), preservando o restante do caminho da URL.

Por exemplo, se você quiser reescrever https://domain.com/us/seg1/seg2/seg3/https://origin.com/seg2/seg3/, será necessário remover o código do país e um segmento /us/seg1/ adicional, mantendo o restante do caminho da URL intacto.

Para conseguir isso, use o formato de variável do servidor {url_path:seg#:length} para capturar segmentos específicos do URL a partir de um número de segmento específico. Neste exemplo, use {url_path:seg2:2147483647} para capturar todos os segmentos que começam de seg2 até o final. O valor 2147483647 (Int32.Max) garante que todos os segmentos restantes sejam incluídos. Para obter mais informações, consulte o formato de variável do servidor.

Captura de tela que mostra como usar a regravação de URL para remover um ou mais segmentos de caminho de URL.

Observação

Ao usar variáveis de servidor, como {url_path} no campo Destino , a configuração Preservar caminho incompatível torna-se menos relevante porque as variáveis de servidor fornecem controle explícito sobre quais partes do caminho de URL incluir.

Cenário 8: Usar regex para reduzir o número de condições de regra e evitar atingir limites

O uso do regex em condições de regra pode reduzir significativamente o número de regras necessárias, o que ajuda a evitar limites de regras que podem ser um bloqueador para clientes que precisam de condições ou ações para centenas de clientes.

Por exemplo, se um cliente quiser identificar seus clientes com um padrão de ID específico para permitir o acesso a um recurso por trás do Azure Front Door, os clientes enviarão um cabeçalho como x-client-id: SN1234-ABCD56. Esse cabeçalho segue um formato específico: x-client-id: <SN + 4 digits + - + 4 uppercase letters + 2 digits>.

Em vez de criar regras individuais para cada ID de cliente possível, você pode usar um único padrão ^SN[0-9]{4}-[A-Z]{4}[0-9]{2}$ regex para corresponder a todas as IDs de cliente válidas em uma regra, por exemplo, SN1234-ABCD56, , SN0001-ZYXW99, SN2025-QWER12, SN9876-MNOP34SN3141-TEST42etc. Essa abordagem permite lidar com centenas de IDs de cliente diferentes com uma única configuração de regra.

Captura de tela que mostra como usar o regex para corresponder aos padrões de ID do cliente.

Observação

Você pode usar regex101 para testar e validar seus padrões regex antes de implementá-los no Azure Front Door.

Cenário 9: Modificar redirecionamentos de origem usando capturas de cabeçalho de resposta

Você pode tornar os campos de ação dinâmicos usando valores de cabeçalho de resposta como variáveis de servidor. Isso é útil quando os servidores de origem emitem redirecionamentos que referenciam seus próprios nomes de domínio.

O problema: Servidores de origem, como o Serviço de Aplicativo do Azure, geralmente emitem URLs de redirecionamento que fazem referência ao seu próprio nome de domínio (por exemplo, contoso.azurewebsites.net). Se essas URLs alcançarem o cliente não modificado, a próxima solicitação ignorará o Azure Front Door, o que interromperá a experiência de navegação do usuário.

A solução: Capture o cabeçalho da Location origem e reescreva apenas a parte do host para que ela sempre reflita o nome do host que o cliente usou originalmente.

Por exemplo, se o cabeçalho de host do cliente front-end para o Azure Front Door for contoso.com e a origem for contoso.azurewebsites.net, quando a origem emitir uma URL de redirecionamento absoluto como Localização: https://contoso.azurewebsites.net/login/, você poderá modificar o cabeçalho de localização para usar o nome do host original Localização: https://contoso.com/login/

Isso é obtido usando o formato de variável de servidor: https://{hostname}{http_resp_header_location:33}, em que:

  • {hostname} representa o nome do host do cliente original (contoso.com)
  • {http_resp_header_location:33} captura o conteúdo do cabeçalho de Localização a partir do deslocamento 33 (a parte /login/)

Para obter mais informações, consulte Preservar o nome do host HTTP original entre um proxy reverso e seu aplicativo Web de back-end.

Captura de tela que mostra como modificar redirecionamentos de origem usando capturas de cabeçalho de resposta.

Observação

  • Essa regra pode ser usada quando a condição de regra é baseada em parâmetros de solicitação ou quando invocada incondicionalmente.

  • Para um cálculo de deslocamento consistente, todos os servidores de origem no grupo de origem devem ter nomes de domínio do mesmo comprimento, por exemplo, todos os 33 caracteres como https://contoso.azurewebsites.net. O ideal é que haja apenas um servidor de origem, mas várias origens serão aceitáveis se seus nomes tiverem comprimentos idênticos.

  • Você pode aplicar a mesma técnica de captura de variável de servidor para extrair e reutilizar parâmetros de cadeia de caracteres de consulta de solicitação em diferentes ações de regra.

Cenário 10: regras If-elseif-else

O mecanismo de regras do Azure Front Door não oferece suporte nativo à lógica condicional tradicional com estruturas "if-elseif-else". Por padrão, todas as regras são avaliadas independentemente como "if condition1 then action1", "if condition2 then action2" e assim por diante. Quando várias condições são atendidas simultaneamente, várias ações correspondentes são executadas.

No entanto, você pode emular a lógica "if-elseif-else" usando o recurso Parar de avaliar as regras restantes para criar ramificação condicional semelhante a:

  • Se a condição1 estiver satisfeita, execute action1 e pare
  • Caso a condição2 seja atendida (mas a condição1 não), execute a ação2 e pare
  • Caso contrário, se a condição3 estiver satisfeita (mas a condição1 e a condição2 não estiverem), execute a ação3 e pare
  • Caso contrário, execute uma ação padrão

Como funciona: quando várias condições normalmente seriam atendidas simultaneamente, apenas a primeira regra correspondente é executada porque a avaliação da regra para após a primeira correspondência. Isso simula efetivamente a ramificação condicional tradicional.

Etapas de configuração:

  1. Criar um novo conjunto de regras (por exemplo, "IfElseifElseRuleset")
  2. Criar regras em ordem de prioridade, com as condições mais específicas primeiro
  3. Para cada regra, verifique a opção Parar de avaliar as regras restantes

Captura de tela que mostra como configurar regras if-elseif-else.

Importante

O paradigma if-elseif-else só funcionará se o conjunto de regras for anexado como o conjunto de regras final para essa rota.

Captura de tela que mostra como colocar regras if-elseif-else como o conjunto de regras final para a rota.

Cenário 11: remover cadeias de caracteres de consulta de URLs recebidas usando redirecionamentos de URL

Você pode remover cadeias de caracteres de consulta de URLs recebidas implementando um redirecionamento de URL 3xx que guie os usuários de volta ao ponto de extremidade do Azure Front Door com as cadeias de caracteres de consulta removidas.

Observação

Os usuários observarão a alteração da URL de solicitação com esta operação.

O exemplo a seguir demonstra como remover toda a cadeia de caracteres de consulta das URLs de entrada. Se precisar remover parte dela, ajuste o deslocamento/comprimento conforme desejado. Para obter mais informações, consulte o formato de variável do servidor.

Captura de tela que mostra como remover cadeias de caracteres de consulta de URLs de entrada usando redirecionamentos de URL 3xx.

Cenário 12: Acrescentar token SAS na cadeia de consulta para autenticar o Azure Front Door no Armazenamento do Azure

Você pode proteger arquivos em sua conta de armazenamento alterando o acesso aos contêineres de armazenamento de público para privado e usando SAS (Assinaturas de Acesso Compartilhado) para conceder direitos de acesso restritos aos seus recursos de Armazenamento do Azure do Azure Front Door sem expor sua chave de conta. Você também pode fazer isso usando a Identidade Gerenciada. Para obter mais informações, confira Usar identidades gerenciadas para autenticar em origens.

Como funciona a injeção de token SAS: Capture o caminho da URL de entrada e acrescente o token SAS à cadeia de caracteres de consulta usando regras de redirecionamento ou regravação. Como a regravação de URL só atua no caminho, use regras de redirecionamento quando precisar modificar cadeias de caracteres de consulta.

Por exemplo, se você quiser acrescentar um token SAS à URL de entrada: https://www.contoso.com/dccp/grammars/0.1.0-59/en-US/grammars/IVR/ssn0100_CollectTIN_QA_dtmf.grxml?version=1.0_1719342835399, a URL de reescrita será: https://www.contoso.com/grammars/0.1.0-59/en-US/grammars/IVR/ssn0100_CollectTIN_QA_dtmf.grxml?version=1.0_1719342835399&<SASTOKEN>

Neste exemplo, a URL de entrada já tem parâmetros de consulta e você deseja preservar a cadeia de caracteres de consulta existente ao acrescentar o token SAS configurando o redirecionamento de URL usando /{url_path:seg1:20}?{query_string}&<SASToken>.

A configuração de regra redireciona todas as solicitações HTTPS que ainda não contêm o token SAS (identificado pela ausência de sp=rl na string de consulta).

Captura de tela que mostra como acrescentar o token SAS na cadeia de caracteres de consulta.

Importante

  • Atualize a configuração de rota para garantir que as rotas /grammars/* sejam configuradas corretamente após o redirecionamento

  • Substitua o token SAS pelo token apropriado. No exemplo, o token SAS começa com sp=rl, e você deseja redirecionar todas as solicitações para aplicar essa regra que não contém o sp=rl

Cenário 13: adicionar cabeçalhos de segurança com o mecanismo de regras

Você pode usar o mecanismo de regras do Azure Front Door para adicionar cabeçalhos de segurança que ajudam a evitar vulnerabilidades baseadas no navegador, como HTTP Strict-Transport-Security (HSTS), X-XSS-Protection, Content-Security-Policy e X-Frame-Options.

Por exemplo, você pode adicionar um cabeçalho Content-Security-Policy a todas as solicitações de entrada que correspondam ao caminho definido na rota associada à configuração do mecanismo de regras. Nessa configuração, use script-src 'self' https://apiphany.portal.azure-api.net como o valor do cabeçalho para permitir apenas scripts do site https://apiphany.portal.azure-api.net confiável a serem executados no aplicativo. Para obter mais informações, consulte Adicionar cabeçalhos de segurança com o motor de regras.

Captura de tela que mostra como adicionar cabeçalhos de segurança com o mecanismo de regras.

Conteúdo relacionado