Configurar Aplicativos Web Estáticos do Azure

Artigo
05/16/2024

Defina a configuração dos Aplicativos Web Estáticos do Azure no arquivo staticwebapp.config.json, que controla as seguintes configurações:

Roteamento
Autenticação
Autorização
Regras de fallback
Substituições de resposta HTTP
Definições de cabeçalho HTTP global
Tipos MIME personalizados
Rede

Observação

Foi preterido o routes.jsem que foi usado anteriormente para configurar o roteamento. Use staticwebapp.config.json conforme descrito neste artigo para definir o roteamento e outras configurações do seu aplicativo Web estático.

Este documento descreve como configurar os Aplicativos Web Estáticos do Azure, um produto autônomo e separado do recurso de hospedagem de site estático do Armazenamento do Azure.

Local do arquivo

O local recomendado para o staticwebapp.config.json está na pasta definida como o app_location no arquivo de fluxo de trabalho. No entanto, você pode colocar o arquivo em qualquer subpasta dentro do conjunto de pastas como o app_location. Além disso, se houver uma etapa de build, você deve garantir que a etapa de build gere o arquivo para a raiz do output_location.

Confira o exemplo do arquivo de configuração para ver detalhes.

Importante

O arquivo routes.json preterido será ignorado se existir um staticwebapp.config.json.

Rotas

Você pode definir regras para uma ou mais rotas em seu aplicativo Web estático. As regras de rota permitem restringir o acesso a usuários em funções específicas ou executar ações como redirecionamento ou reescrita. As rotas são definidas como uma matriz de regras de roteamento. Confira o exemplo de arquivo de configuração para obter exemplos de uso.

As regras são definidas na matriz routes, mesmo se você tiver apenas uma rota.
As regras são avaliadas na ordem em que aparecem na matriz de routes.
A avaliação da regra é interrompida na primeira correspondência. Uma combinação ocorre quando a propriedade route e um valor na matriz methods (se especificado) corresponderem à solicitação. Cada solicitação pode corresponder a no máximo uma regra.

As preocupações de roteamento se sobrepõem significativamente com os conceitos de autenticação (identificação do usuário) e autenticação (atribuição de capacidades ao usuário). Certifique-se de ler o guia de autenticação e autorização, juntamente com este artigo.

Definir rotas

Cada regra é composta por um padrão de rota, juntamente com uma ou mais das propriedades de regra opcionais. As regras de rota são definidas na matriz routes. Confira o exemplo de arquivo de configuração para obter exemplos de uso.

Importante

Somente as propriedades route e methods (se especificadas) são usadas para determinar se uma regra corresponde a uma solicitação.

Propriedade de regra	Obrigatório	Valor padrão	Comentário
`route`	Sim	n/d	O padrão de rota solicitado pelo chamador. Há suporte para curingas no final dos caminhos de rota. Por exemplo, a rota /admin* corresponde a qualquer rota que comece com /admin.
`methods`	Não	Todos os métodos	Define uma matriz de métodos de solicitação que correspondem a uma rota. Os métodos disponíveis incluem: `GET`, `HEAD`, `POST`, `PUT`, `DELETE`, `CONNECT`, `OPTIONS`, `TRACE` e `PATCH`.
`rewrite`	Não	n/d	Define o arquivo ou caminho retornado da solicitação. É mutuamente exclusivo para uma regra `redirect`. Regras de regeneração não alteram o local do navegador. Os valores precisam ser relativos à raiz do aplicativo.
`redirect`	Não	N/D	Define o destino de redirecionamento do arquivo ou caminho para uma solicitação. É mutuamente exclusivo para uma regra `rewrite`. As regras de redirecionamento alteram o local do navegador. O código de resposta padrão é um `302` (redirecionamento temporário), mas você pode substituí-lo por um `301` (redirecionamento permanente).
`statusCode`	Não	`301` ou `302` para redirecionamentos	O código de status HTTP da resposta.
`headers`	Não	N/D	Conjunto de cabeçalhos HTTP adicionado à resposta. Os cabeçalhos específicos de rota substituem `globalHeaders` quando o cabeçalho específico de rota é o mesmo que o cabeçalho global que está na resposta. Para remover um cabeçalho, defina o valor dele como uma cadeia de caracteres vazia.
`allowedRoles`	Não	anônimo	Define uma matriz de nomes de função necessários para acessar uma rota. Os caracteres válidos incluem `a-z`, `A-Z`, `0-9` e `_`. A função interna, `anonymous`, se aplica a todos os usuários. A função interna, `authenticated`, se aplica a todos os usuários que fizeram logon. Os usuários devem pertencer a pelo menos uma função. As funções são comparadas usando o operador OR. Se um usuário estiver em qualquer uma das funções listadas, o acesso será concedido. Os usuários individuais são associados a funções por meio de convites.

Cada propriedade tem uma finalidade específica no pipeline de solicitação/resposta.

Finalidade	Propriedades
Fazer a correspondência de rotas	`route`, `methods`
Fazer o processamento depois que uma regra for correspondida e autorizada	`rewrite` (modifica a solicitação) `redirect`, `headers`, `statusCode` (modifica a resposta)
Dar autorização após a correspondência de uma rota	`allowedRoles`

Especificar padrões de rota

A propriedade route pode ser uma rota exata ou um padrão curinga.

Rota exata

Para definir uma rota exata, coloque o caminho completo do arquivo na propriedade route.

{
  "route": "/profile/index.html",
  "allowedRoles": ["authenticated"]
}

Essa regra corresponde às solicitações para o arquivo /profile/index.html. Como index.html é o arquivo padrão, a regra também corresponde às solicitações da pasta (/profile ou /profile/).

Importante

Se você usar um caminho de pasta (/profile ou /profile/) na propriedade route, ele não corresponderá a solicitações para o arquivo /profile/index.html. Ao proteger uma rota que serve um arquivo, sempre use o caminho completo do arquivo, como /profile/index.html.

Padrão de curinga

As regras curinga correspondem a todas as solicitações em um padrão de rota e só têm suporte no final de um caminho. Confira o exemplo de arquivo de configuração para obter exemplos de uso.

Por exemplo, para implementar rotas para um aplicativo de calendário, você pode regenerar todas as URLs que se enquadram na rota calendário para atender a um único arquivo.

{
  "route": "/calendar*",
  "rewrite": "/calendar.html"
}

O arquivo calendar.html pode, então, usar o roteamento do lado do cliente para atender a uma exibição diferente para variações de URL, como /calendar/january/1, /calendar/2020 e /calendar/overview.

Observação

Um padrão de rota de /calendar/* corresponde a todas as solicitações no caminho /calendar/. No entanto, ele não corresponderá às solicitações para os caminhos /calendar ou /calendar.html. Use /calendar* para corresponder a todas as solicitações que começam com /calendar.

Você pode filtrar correspondências curinga por extensão de arquivo. Por exemplo, se você quisesse adicionar uma regra que só corresponde a arquivos HTML em um determinado caminho, você poderia criar a seguinte regra:

{
  "route": "/articles/*.html",
  "headers": {
    "Cache-Control": "public, max-age=604800, immutable"
  }
}

Para filtrar várias extensões de arquivo, inclua as opções entre chaves, conforme mostrado neste exemplo:

{
  "route": "/images/thumbnails/*.{png,jpg,gif}",
  "headers": {
    "Cache-Control": "public, max-age=604800, immutable"
  }
}

Os casos de uso comuns de rotas curinga incluem:

Fornecer um arquivo específico para um padrão de caminho inteiro
Impor regras de autenticação e autorização
Implementar regras de cache especializadas

Proteger as rotas com funções

As rotas são protegidas pela adição de um ou mais nomes de função na matriz de allowedRoles de uma regra. Confira o exemplo de arquivo de configuração para obter exemplos de uso.

Importante

As regras de roteamento só podem proteger solicitações HTTP para rotas que são atendidas pelos Aplicativos Web Estáticos. Muitas estruturas de front-end usam o roteamento do lado do cliente que modifica rotas no navegador sem emitir solicitações para Aplicativos Web Estáticos. As regras de roteamento não protegem as rotas do lado do cliente. Os clientes devem chamar as APIs HTTP para recuperar dados confidenciais. Verifique se as APIs validam a identidade de um usuário antes de retornar os dados.

Por padrão, cada usuário pertence à função anonymous interna e todos os usuários conectados são membros da função authenticated. Opcionalmente, os usuários são associados a funções personalizadas por meio de convites.

Por exemplo, para restringir uma rota somente a usuários autenticados, adicione a função authenticated interna à matriz de allowedRoles.

{
  "route": "/profile*",
  "allowedRoles": ["authenticated"]
}

Você pode criar novas funções conforme necessário na matriz de allowedRoles. Para restringir uma rota a apenas administradores, você pode definir a própria função chamada de administrator, na matriz allowedRoles.

{
  "route": "/admin*",
  "allowedRoles": ["administrator"]
}

Você tem controle total sobre os nomes de função; não há nenhuma lista à qual suas funções devem se ater.
Os usuários individuais são associados a funções por meio de convites.

Importante

Ao proteger o conteúdo, especifique os arquivos exatos, quando possível. Se você tiver muitos arquivos para proteger, use curingas após um prefixo compartilhado. Por exemplo: /profile* protege todas as rotas possíveis que começam com /profile, incluindo /profile.

Restringir o acesso a todo o aplicativo

Muitas vezes você quer requerer autenticação para cada rota em seu aplicativo. Para bloquear suas rotas, adicione uma regra que corresponda a todas as rotas e inclua a função interna authenticated na matriz allowedRoles.

A configuração de exemplo a seguir bloqueia o acesso anônimo e redireciona todos os usuários não autenticados para a página de entrada do Microsoft Entra.

{
  "routes": [
    {
      "route": "/*",
      "allowedRoles": ["authenticated"]
    }
  ],
  "responseOverrides": {
    "401": {
      "statusCode": 302,
      "redirect": "/.auth/login/aad"
    }
  }
}

Observação

Por padrão, todos os provedores de identidade pré-configurados estão habilitados. Para bloquear um provedor de autenticação, veja Autenticação e autorização.

Rotas de fallback

Aplicativos de página única geralmente dependem do roteamento do lado do cliente. Essas regras de roteamento do lado do cliente atualizam o local da janela do navegador sem fazer solicitações de volta ao servidor. Se você atualizar a página ou acessar diretamente as URLs geradas pelas regras de roteamento do lado do cliente, uma rota de fallback do lado do servidor será necessária para atender à página HTML apropriada. A página de fallback geralmente é designada como index.html para seu aplicativo do lado do cliente.

É possível definir uma regra de fallback adicionando uma seção navigationFallback. O exemplo a seguir retorna /index.html para todas as solicitações de arquivo estático que não correspondem a um arquivo implantado.

{
  "navigationFallback": {
    "rewrite": "/index.html"
  }
}

Você pode controlar quais solicitações retornam o arquivo de fallback por meio da definição de um filtro. No exemplo a seguir, as solicitações para determinadas rotas na pasta /images e todos os arquivos na pasta /css são excluídos do retorno do arquivo de fallback.

{
  "navigationFallback": {
    "rewrite": "/index.html",
    "exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
  }
}

Por exemplo, com a estrutura de diretório a seguir, a regra de fallback de navegação acima produzirá os resultados detalhados na tabela a seguir.

├── images
│   ├── logo.png
│   ├── headshot.jpg
│   └── screenshot.gif
│
├── css
│   └── global.css
│
├── about.html
└── index.html

Solicitações para...	retorna...	com o status...
/about/	O arquivo /index.html.	`200`
/images/logo.png	O arquivo de imagem.	`200`
/images/icon.svg	O arquivo /index.html, pois a extensão de arquivo svg não está listada no filtro `/images/*.{png,jpg,gif}`.	`200`
/images/unknown.png	Erro de arquivo não encontrado.	`404`
/css/unknown.css	Erro de arquivo não encontrado.	`404`
/css/global.css	O arquivo de folha de estilos.	`200`
/about.html	A página HTML.	`200`
Qualquer outro caminho fora das pastas /images ou /css que não correspondam ao caminho para um arquivo implantado.	O arquivo /index.html.	`200`

Importante

Se você estiver migrando de um arquivo routes.json preterido, não inclua a rota de fallback herdada ("route": "/*") nas regras de roteamento.

Cabeçalhos globais

A seção globalHeaders fornece um conjunto de cabeçalhos HTTP aplicado a cada resposta, a menos que seja substituído por uma regra de cabeçalho de rota; caso contrário, a união dos cabeçalhos da rota e globais será retornada.

Confira o exemplo de arquivo de configuração para obter exemplos de uso.

Para remover um cabeçalho, defina o valor dele como uma cadeia de caracteres ("") vazia.

Alguns casos de uso comuns dos cabeçalhos globais incluem:

Personalizar regras de cache
Políticas de segurança
Configurações de codificação
Configuração de compartilhamento de recursos entre origens (CORS)

O exemplo a seguir implementa uma configuração de CORS personalizada.

{
  "globalHeaders": {
    "Access-Control-Allow-Origin": "https://example.com",
    "Access-Control-Allow-Methods": "POST, GET, OPTIONS"
  }
}

Observação

Os cabeçalhos globais não afetam as respostas da API. Os cabeçalhos nas respostas da API são preservados e retornados ao cliente.

Substituições de resposta

A seção responseOverrides fornece uma oportunidade para definir uma resposta personalizada quando o servidor retornasse, de outra forma, um código de erro. Confira o exemplo de arquivo de configuração para obter exemplos de uso.

Os seguintes códigos HTTP estão disponíveis para substituição:

Código de status	Significado	Causa possível
400	Solicitação incorreta	Link de convite inválido
401	Não Autorizado	Solicitação para páginas restritas enquanto a autenticação não foi realizada
403	Proibido	O usuário fez logon, mas não tem as funções necessárias para exibir a página. O usuário está conectado, mas o runtime não pode obter os detalhes do usuário com base nas declarações de identidade dele. Há muitos usuários que fizeram logon no site com funções personalizadas. Portanto, o runtime não pode conectar o usuário.
404	Não encontrado	Arquivo não encontrado

A configuração de exemplo a seguir demonstra como substituir um código de erro.

{
  "responseOverrides": {
    "400": {
      "rewrite": "/invalid-invitation-error.html"
    },
    "401": {
      "statusCode": 302,
      "redirect": "/login"
    },
    "403": {
      "rewrite": "/custom-forbidden-page.html"
    },
    "404": {
      "rewrite": "/custom-404.html"
    }
  }
}

Plataforma

A seção platform controla as configurações específicas da plataforma, como a versão de runtime da linguagem de API.

Selecionar a versão de runtime da linguagem de API

Para configurar a versão de runtime da linguagem de API, defina a propriedade apiRuntime na seção platform como um dos valores com suporte a seguir.

Versão de runtime da linguagem	Sistema operacional	Versão do Azure Functions	`apiRuntime` valor	Data de fim do suporte
.NET Core 3.1	Windows	3.x	`dotnet:3.1`	3 de dezembro de 2022
.NET 6.0 em processo	Windows	4.x	`dotnet:6.0`	-
.NET 6.0 isolado	Windows	4.x	`dotnet-isolated:6.0`	-
.NET 7.0 isolado	Windows	4.x	`dotnet-isolated:7.0`	-
.NET 8.0 isolado	Windows	4.x	`dotnet-isolated:8.0`	-
Node.js 12.x	Linux	3.x	`node:12`	3 de dezembro de 2022
Node.js 14.x	Linux	4.x	`node:14`	-
Node.js 16.x	Linux	4.x	`node:16`	-
Node.js 18.x	Linux	4.x	`node:18`	-
Python 3.8	Linux	4.x	`python:3.8`	-
Python 3.9	Linux	4.x	`python:3.9`	-
Python 3.10	Linux	4.x	`python:3.10`	-

.NET

Para alterar a versão do runtime em um aplicativo .NET, altere o valor de TargetFramework no arquivo csproj. Embora isso seja opcional, se você definir um valor de apiRuntime no arquivo staticwebapp.config.json, verifique se o valor corresponde ao que definido no arquivo csproj.

O exemplo a seguir demonstra como atualizar o elemento TargetFramework para o NET 8.0 como a versão de runtime da linguagem da API no arquivo csproj.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    ...
  </PropertyGroup>
...

Node.js

A configuração de exemplo a seguir demonstra como usar a propriedade apiRuntime para selecionar o Node.js 16 como a versão de runtime da linguagem da API no arquivo staticwebapp.config.json.

{
  ...
  "platform": {
    "apiRuntime": "node:16"
  }
  ...
}

Python

A configuração de exemplo a seguir demonstra como usar a propriedade apiRuntime para selecionar o Python 3.8 como a versão de runtime da linguagem da API no arquivo staticwebapp.config.json.

{
  ...
  "platform": {
    "apiRuntime": "python:3.8"
  }
  ...
}

Rede

A seção networking controla a configuração de rede do aplicativo Web estático. Para restringir o acesso ao aplicativo, especifique uma lista de blocos de endereço IP permitidos em allowedIpRanges. Para obter mais informações sobre o número de blocos de endereços IP permitidos, consulte Cotas em Aplicativos Web Estáticos do Azure.

Observação

A configuração de rede só está disponível no plano Standard dos Aplicativos Web Estáticos do Azure.

Defina cada bloco de endereço IPv4 na notação CIDR (Roteamento entre Domínios sem Classificação). Para saber mais sobre a notação CIDR, confira Roteamento entre domínios sem classe. Cada bloco de endereço IPv4 pode indicar um espaço de endereço público ou privado. Se você quiser apenas permitir o acesso de um endereço IP, use o bloco CIDR /32.

{
  "networking": {
    "allowedIpRanges": [
      "10.0.0.0/24",
      "100.0.0.0/32",
      "192.168.100.0/22"
    ]
  }
}

Quando um ou mais blocos de endereço IP são especificados, as solicitações provenientes de endereços IP que não corresponderem a um valor em allowedIpRanges terão o acesso negado.

Além dos blocos de endereços IP, você também pode especificar marcas de serviço na matriz allowedIpRanges para restringir o tráfego a determinados serviços do Azure.

"networking": {
  "allowedIpRanges": ["AzureFrontDoor.Backend"]
}

Autenticação

Provedores de autenticação padrão não exigem definições no arquivo de configuração.
Os provedores de autenticação personalizados usam a seção auth do arquivo de configurações.

Para obter detalhes sobre como restringir rotas a usuários autenticados, consulte Proteger rotas com funções.

Desabilitar o cache para caminhos autenticados

Se configurar a integração manual com o Azure Front Door, você talvez queira desabilitar o armazenamento cache para suas rotas protegidas. Com a borda de nível empresarial habilitada, o cache já está desabilitado para suas rotas seguras.

Para desabilitar o cache do Azure Front Door para rotas protegidas, adicione "Cache-Control": "no-store" à definição do cabeçalho de rota.

Por exemplo:

{
    "route": "/members",
    "allowedRoles": ["authenticated, members"],
    "headers": {
        "Cache-Control": "no-store"
    }
}

Gateway de encaminhamento

A seção forwardingGateway configura como um aplicativo web estático é acessado de um gateway de encaminhamento, como uma CDN (Rede de Distribuição de Conteúdo) ou Azure Front Door.

Observação

A configuração gateway de encaminhamento só está disponível no plano Standard dos Aplicativos Web Estáticos do Azure.

Hosts encaminhados permitidos

A lista allowedForwardedHosts especifica quais nomes de host aceitar no cabeçalho de host X encaminhado. Se um domínio correspondente estiver na lista, os Aplicativos Web Estáticos usarão o valor X-Forwarded-Host ao construir URLs de redirecionamento, como após uma entrada bem-sucedida.

Para que aplicativos Web estáticos funcionem corretamente por trás de um gateway de encaminhamento, a solicitação do gateway deve incluir o nome de host correto no cabeçalho X-Forwarded-Host e o mesmo nome de host deve ser listado emallowedForwardedHosts.

"forwardingGateway": {
  "allowedForwardedHosts": [
    "example.org",
    "www.example.org",
    "staging.example.org"
  ]
}

Se o cabeçalho X-Forwarded-Host não corresponder a um valor na lista, as solicitações ainda serão realizadas, mas o cabeçalho não será usado na resposta.

Cabeçalhos necessários

Os cabeçalhos necessários são cabeçalhos HTTP que devem ser enviados com cada solicitação ao seu site. Um uso dos cabeçalhos necessários é negar o acesso a um site, a menos que todos os cabeçalhos necessários estejam presentes em cada solicitação.

Por exemplo, a configuração a seguir mostra como você pode adicionar um identificador exclusivo para o Azure Front Door que limita o acesso ao seu site de uma instância específica do Azure Front Door. Consulte o Tutorial configurar o Azure Front Door para obter detalhes completos.

"forwardingGateway": {
  "requiredHeaders": {
    "X-Azure-FDID" : "692a448c-2b5d-4e4d-9fcc-2bc4a6e2335f"
  }
}

Pares de chave/valor podem ser qualquer conjunto de cadeias de caracteres arbitrárias
As chaves não diferenciam maiúsculas e minúsculas
Os valores diferenciam maiúsculas de minúsculas

Barra à direita

Uma barra à direita é o / no final de uma URL. Convencionalmente, uma URL com barra à direita se refere a um diretório no servidor Web, enquanto uma URL sem barra à direita indica um arquivo.

Os mecanismos de pesquisa tratam as duas URLs separadamente, sem importar se é um arquivo ou um diretório. Quando o mesmo conteúdo é renderizado em ambas as URLs, o site fornece um conteúdo duplicado, o que pode afetar negativamente a SEO (otimização do mecanismo de pesquisa). Quando configurados explicitamente, os Aplicativos Web Estáticos aplicam um conjunto de regras de normalização e redirecionamento de URL que ajudam a melhorar o desempenho e a SEO do site.

As seguintes regras de normalização e redirecionamento se aplicam a cada uma das configurações disponíveis:

Sempre

Quando você define trailingSlash como always, todas as solicitações que não incluem uma barra à direita são redirecionadas para uma URL com barra à direita. Por exemplo, /contact é redirecionado para /contact/.

"trailingSlash": "always"

Solicitações para...	retorna...	com o status...	e caminho...
/about	O arquivo /about/index.html	`301`	/about/
/about/	O arquivo /about/index.html	`200`	/about/
/about/index.html	O arquivo /about/index.html	`301`	/about/
/contact	O arquivo /contact.html	`301`	/contact/
/contact/	O arquivo /contact.html	`200`	/contact/
/contact.html	O arquivo /contact.html	`301`	/contact/

Nunca

Ao definir trailingSlash como never, todas as solicitações que terminam com uma barra à direita são redirecionadas para uma URL sem barra à direita. Por exemplo, /contact/ é redirecionado para /contact.

"trailingSlash": "never"

Solicitações para...	retorna...	com o status...	e caminho...
/about	O arquivo /about/index.html	`200`	/about
/about/	O arquivo /about/index.html	`301`	/about
/about/index.html	O arquivo /about/index.html	`301`	/about
/contact	O arquivo /contact.html	`200`	/contact
/contact/	O arquivo /contact.html	`301`	/contact
/contact.html	O arquivo /contact.html	`301`	/contact

Auto

Quando você define trailingSlash como auto, todas as solicitações para pastas são redirecionadas para uma URL com uma barra à direita. Todas as solicitações para arquivos são redirecionadas para uma URL sem barra à direita.

"trailingSlash": "auto"

Solicitações para...	retorna...	com o status...	e caminho...
/about	O arquivo /about/index.html	`301`	/about/
/about/	O arquivo /about/index.html	`200`	/about/
/about/index.html	O arquivo /about/index.html	`301`	/about/
/contact	O arquivo /contact.html	`200`	/contact
/contact/	O arquivo /contact.html	`301`	/contact
/contact.html	O arquivo /contact.html	`301`	/contact

Para obter o desempenho ideal do site, configure uma estratégia de barra à direita usando um entre os modos always, never ou auto.

Por padrão, quando a configuração trailingSlash é omitida, os Aplicativos Web Estáticos aplicam as seguintes regras:

Solicitações para...	retorna...	com o status...	e caminho...
/about	O arquivo /about/index.html	`200`	/about
/about/	O arquivo /about/index.html	`200`	/about/
/about/index.html	O arquivo /about/index.html	`200`	/about/index.html
/contact	O arquivo /contact.html	`200`	/contact
/contact/	O arquivo /contact.html	`301`	/contact
/contact.html	O arquivo /contact.html	`200`	/contact.html

Exemplo de arquivo de configuração

{
  "trailingSlash": "auto",
  "routes": [
    {
      "route": "/profile*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/admin/index.html",
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/images/*",
      "headers": {
        "cache-control": "must-revalidate, max-age=15770000"
      }
    },
    {
      "route": "/api/*",
      "methods": ["GET"],
      "allowedRoles": ["registeredusers"]
    },
    {
      "route": "/api/*",
      "methods": ["PUT", "POST", "PATCH", "DELETE"],
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/api/*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/customers/contoso*",
      "allowedRoles": ["administrator", "customers_contoso"]
    },
    {
      "route": "/login",
      "rewrite": "/.auth/login/github"
    },
    {
      "route": "/.auth/login/twitter",
      "statusCode": 404
    },
    {
      "route": "/logout",
      "redirect": "/.auth/logout"
    },
    {
      "route": "/calendar*",
      "rewrite": "/calendar.html"
    },
    {
      "route": "/specials",
      "redirect": "/deals",
      "statusCode": 301
    }
  ],
  "navigationFallback": {
    "rewrite": "index.html",
    "exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
  },
  "responseOverrides": {
    "400": {
      "rewrite": "/invalid-invitation-error.html"
    },
    "401": {
      "redirect": "/login",
      "statusCode": 302
    },
    "403": {
      "rewrite": "/custom-forbidden-page.html"
    },
    "404": {
      "rewrite": "/404.html"
    }
  },
  "globalHeaders": {
    "content-security-policy": "default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'"
  },
  "mimeTypes": {
    ".json": "text/json"
  }
}

Com base na configuração acima, examine os cenários a seguir.

Solicitações para...	resulta em...
/profile	Os usuários autenticados recebem o arquivo /profile/index.html. Usuários não autenticados são redirecionados para /login pela regra de substituição de resposta `401`.
/admin, /admin/ ou /admin/index.html	Os usuários autenticados na função administrator recebem o arquivo /admin/index.html. Os usuários autenticados que não estão na função administrator recebem um erro `403`¹. Usuários não autenticados são redirecionados para /login
/images/logo.png	Fornece a imagem com uma regra de cache personalizada em que a idade máxima é um pouco maior que 182 dias (15.770.000 segundos).
/api/admin	As solicitações `GET` de usuários autenticados na função registeredusers são enviadas para a API. Os usuários autenticados que não estão na função registeredusers e usuários não autenticados recebem um erro `401`. As solicitações `POST`, `PUT`, `PATCH` e `DELETE` de usuários autenticados na função administrator são enviadas para a API. Os usuários autenticados que não estão na função administrator e usuários não autenticados recebem um erro `401`.
/customers/contoso	Usuários autenticados que pertencem à função administrator ou customers_contoso recebem o arquivo /customers/contoso/index.html. Usuários autenticados que não estão na função administrator ou customers_contoso recebem um erro `403`¹. Usuários não autenticados são redirecionados para /login.
/login	Os usuários não autenticados são desafiados a autenticar com o GitHub.
/.auth/login/twitter	Como a regra de rota desabilita a autorização do Twitter (X), será retornado um erro `404`. Em seguida, esse erro fará um fallback para distribuir /index.html com um código de status `200`.
/logout	Os usuários são desconectados de qualquer provedor de autenticação.
/calendar/2021/01	O navegador recebe o arquivo /calendar.html.
/specials	O navegador é redirecionado permanentemente para /deals.
/data.json	O arquivo fornecido com o tipo MIME `text/json`.
/about ou qualquer pasta que corresponda aos padrões de roteamento do lado do cliente	O arquivo /index.html é fornecido com um código de status `200`.
Um arquivo não existente na pasta /images/	Um erro `404`.

¹ Você pode fornecer uma página de erro personalizada usando uma regra de substituição de resposta.

Restrições

As restrições a seguir existem para o arquivo staticwebapps.config.json.

O tamanho máximo do arquivo é de 20 KB
Máximo de 50 funções diferentes

Confira o artigo Cotas para ver as restrições gerais e limitações.

Próximas etapas

Configurar a autenticação e a autorização

Compartilhar via

Configurar Aplicativos Web Estáticos do Azure

Local do arquivo

Rotas

Definir rotas

Especificar padrões de rota

Rota exata

Padrão de curinga

Proteger as rotas com funções

Restringir o acesso a todo o aplicativo

Rotas de fallback

Cabeçalhos globais

Substituições de resposta

Plataforma

Selecionar a versão de runtime da linguagem de API

.NET

Node.js

Python

Rede

Autenticação

Desabilitar o cache para caminhos autenticados

Gateway de encaminhamento

Hosts encaminhados permitidos

Cabeçalhos necessários

Barra à direita

Sempre

Nunca

Auto

Exemplo de arquivo de configuração

Restrições

Próximas etapas

Recursos adicionais

Compartilhar via

Configurar Aplicativos Web Estáticos do Azure

Local do arquivo

Rotas

Definir rotas

Especificar padrões de rota

Rota exata

Padrão de curinga

Proteger as rotas com funções

Restringir o acesso a todo o aplicativo

Rotas de fallback

Cabeçalhos globais

Substituições de resposta

Plataforma

Selecionar a versão de runtime da linguagem de API

.NET

Node.js

Python

Rede

Autenticação

Desabilitar o cache para caminhos autenticados

Gateway de encaminhamento

Hosts encaminhados permitidos

Cabeçalhos necessários

Barra à direita

Sempre

Nunca

Auto

Exemplo de arquivo de configuração

Restrições

Próximas etapas

Artigos relacionados

Recursos adicionais