Configurar Aplicativos Web Estáticos do Azure

Artigo
10/18/2023

Você pode definir a configuração para os Aplicativos Web Estáticos do Azure no arquivo staticwebapp.config.json , que controla as seguintes configurações:

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

Nota

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

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

Localização do ficheiro

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

Consulte o arquivo de configuração de exemplo para obter 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 redirecionar ou reescrever. As rotas são definidas como uma matriz de regras de roteamento. Consulte o arquivo de configuração de exemplo para obter exemplos de uso.

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

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

Definir rotas

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

Importante

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

Propriedade Rule	Necessário	Default value	Comment
`route`	Sim	n/d	O padrão de rota solicitado pelo chamador. Os curingas são suportados 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`, `TRACEOPTIONS`, e `PATCH`.
`rewrite`	No	n/d	Define o arquivo ou caminho retornado da solicitação. Exclui-se mutuamente de uma `redirect` regra. As regras de reescrita não alteram a localização do navegador. Os valores devem ser relativos à raiz do aplicativo.
`redirect`	No	n/d	Define o destino do redirecionamento de arquivo ou caminho para uma solicitação. Exclui-se mutuamente de uma `rewrite` regra. As regras de redirecionamento alteram a localização do navegador. O código de resposta padrão é um `302` (redirecionamento temporário), mas você pode substituir por um `301` (redirecionamento permanente).
`statusCode`	Não	`301` ou `302` para redirecionamentos	O código de status HTTP da resposta.
`headers`	No	n/d	Conjunto de cabeçalhos HTTP adicionados à resposta. Os cabeçalhos específicos da rota substituem `globalHeaders` quando o cabeçalho específico da rota é o mesmo que o cabeçalho global está na resposta. Para remover um cabeçalho, defina o valor 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`, aplica-se a todos os usuários. A função interna, `authenticated`, aplica-se a qualquer utilizador com sessão iniciada. Os usuários devem pertencer a pelo menos uma função. As funções são correspondidas com base em 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.

Propósito	Propriedades
Rotas de correspondência	`route`, `methods`
Processo depois que uma regra é correspondida e autorizada	`rewrite` (modifica o pedido) `redirect`, `headers`, `statusCode` (modifica a resposta)
Autorizar depois que uma rota é correspondida	`allowedRoles`

Especificar padrões de rota

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

Rota exata

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

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

Esta 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 para a pasta (/profile ou /profile/).

Importante

Se você usar um caminho de pasta (/profile ou /profile/) na route propriedade, ele não corresponderá às 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 curinga

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

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

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

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

Nota

Um padrão de rota corresponde /calendar/* 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 correspondesse apenas a arquivos HTML em um determinado caminho, 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 em chaves curvas, conforme mostrado neste exemplo:

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

Os casos de uso comuns para rotas curinga incluem:

Servindo um arquivo específico para um padrão de caminho inteiro
Aplicação de regras de autenticação e autorização
Implementando regras de cache especializadas

Rotas seguras com funções

As rotas são protegidas adicionando um ou mais nomes de função à matriz de allowedRoles uma regra. Consulte o arquivo de configuração de exemplo para obter exemplos de uso.

Importante

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

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

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

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

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

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

Você tem controle total sobre os nomes das funções; não há nenhuma lista à qual suas funções devam aderir.
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ê desejará exigir 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 allowedRoles matriz.

O exemplo de configuração 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"
    }
  }
}

Nota

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

Rotas de fallback

Os 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 ir diretamente para URLs geradas por regras de roteamento do lado do cliente, uma rota de fallback do lado do servidor será necessária para servir a página HTML apropriada. A página de fallback geralmente é designada como index.html para seu aplicativo do lado do cliente.

Você pode definir uma regra de fallback adicionando uma navigationFallback seção. 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 definindo 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 seguinte estrutura de diretórios, a regra de fallback de navegação acima resultaria nos resultados detalhados na tabela a seguir.

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

Pedidos para...	devoluções...	com o estatuto...
/sobre/	O arquivo /index.html .	`200`
/imagens/logo.png	O arquivo de imagem.	`200`
/imagens/icon.svg	O arquivo /index.html - já que a extensão de arquivo svg não está listada `/images/*.{png,jpg,gif}` no filtro.	`200`
/imagens/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 estilo.	`200`
Qualquer outro arquivo fora das pastas /images ou /css	O arquivo /index.html .	`200`

Importante

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

Cabeçalhos globais

A globalHeaders seção fornece um conjunto de cabeçalhos HTTP aplicados 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 dos cabeçalhos globais será retornada.

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

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

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

Regras personalizadas de colocação em 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 CORS personalizada.

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

Nota

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 responseOverrides seção fornece uma oportunidade para definir uma resposta personalizada quando o servidor retornaria um código de erro. Consulte o arquivo de configuração de exemplo para obter exemplos de uso.

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

Código de Estado	Significado	Causa possível
400	Mau pedido	Link de convite inválido
401	Não autorizado	Solicitação para páginas restritas enquanto não autenticadas
403	Proibido	O usuário está conectado, mas não tem as funções necessárias para exibir a página. O usuário está conectado, mas o tempo de execução não pode obter os detalhes do usuário de suas declarações de identidade. Há muitos usuários conectados ao site com funções personalizadas, portanto, o tempo de execução não pode entrar no usuário.
404	Não encontrado	Ficheiro não encontrado

O exemplo de configuração 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 platform seção controla configurações específicas da plataforma, como a versão do tempo de execução da linguagem da API.

Selecione a versão do tempo de execução do idioma da API

Para configurar a versão do tempo de execução da linguagem da API, defina a apiRuntimeplatform propriedade na seção como um dos seguintes valores suportados.

Versão do tempo de execução da linguagem	Sistema operativo	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 (pré-visualização pública)	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 de tempo de execução em um aplicativo .NET, altere o TargetFrameworkvalor no arquivo csproj . Embora seja opcional, se você definir um apiRuntime valor no arquivo staticwebapp.config.json , verifique se o valor corresponde ao que você define no arquivo csproj .

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

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

Node.js

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

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

Python

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

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

Rede

A networking seção controla a configuração de rede do seu aplicativo Web estático. Para restringir o acesso ao seu aplicativo, especifique uma lista de blocos de endereços 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.

Nota

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

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

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

Quando um ou mais blocos de endereços IP são especificados, as solicitações originadas de endereços IP que não correspondem a um valor em allowedIpRanges têm acesso negado.

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

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

Autenticação

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

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

Desativar cache para caminhos autenticados

Se você configurar a integração manual com o Azure Front Door, convém desabilitar o cache para suas rotas seguras. Com a borda de nível empresarial habilitada, o cache já está desativado para suas rotas seguras.

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

Por exemplo:

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

Gateway de encaminhamento

A forwardingGateway seção configura como um aplicativo Web estático é acessado a partir de um gateway de encaminhamento, como uma Rede de Entrega de Conteúdo (CDN) ou a Porta Frontal do Azure.

Nota

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

Hosts encaminhados permitidos

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

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

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

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

Cabeçalhos obrigatórios

Os cabeçalhos necessários são cabeçalhos HTTP que devem ser enviados com cada solicitação para o 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 a partir 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"
  }
}

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

Barra à direita

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

Os mecanismos de pesquisa tratam os dois URLs separadamente, independentemente de ser um arquivo ou um diretório. Quando o mesmo conteúdo é renderizado em ambos os URLs, seu site veicula conteúdo duplicado, o que pode afetar negativamente a otimização para mecanismos de pesquisa (SEO). Quando explicitamente configurado, o Static Web Apps aplica um conjunto de regras de normalização e redirecionamento de URL que ajudam a melhorar o desempenho e o SEO do seu site.

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

Sempre

Quando estiver a definir trailingSlash como always, todos os pedidos que não incluam uma barra à direita são redirecionados para um URL de barra à direita. Por exemplo, /contact é redirecionado para /contact/.

"trailingSlash": "always"

Pedidos para...	devoluções...	com o estatuto...	e caminho...
/sobre	O arquivo /about/index.html	`301`	/sobre/
/sobre/	O arquivo /about/index.html	`200`	/sobre/
/about/index.html	O arquivo /about/index.html	`301`	/sobre/
/contato	O arquivo /contact.html	`301`	/contato/
/contato/	O arquivo /contact.html	`200`	/contato/
/contact.html	O arquivo /contact.html	`301`	/contato/

Nunca

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

"trailingSlash": "never"

Pedidos para...	devoluções...	com o estatuto...	e caminho...
/sobre	O arquivo /about/index.html	`200`	/sobre
/sobre/	O arquivo /about/index.html	`301`	/sobre
/about/index.html	O arquivo /about/index.html	`301`	/sobre
/contato	O arquivo /contact.html	`200`	/contato
/contato/	O arquivo /contact.html	`301`	/contato
/contact.html	O arquivo /contact.html	`301`	/contato

Automático

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 de barra não à direita.

"trailingSlash": "auto"

Pedidos para...	devoluções...	com o estatuto...	e caminho...
/sobre	O arquivo /about/index.html	`301`	/sobre/
/sobre/	O arquivo /about/index.html	`200`	/sobre/
/about/index.html	O arquivo /about/index.html	`301`	/sobre/
/contato	O arquivo /contact.html	`200`	/contato
/contato/	O arquivo /contact.html	`301`	/contato
/contact.html	O arquivo /contact.html	`301`	/contato

Para um desempenho ideal do site, configure uma estratégia de barra à direita usando um dos alwaysmodos , neverou auto .

Por padrão, quando a configuração é omitida, o trailingSlash Static Web Apps aplica as seguintes regras:

Pedidos para...	devoluções...	com o estatuto...	e caminho...
/sobre	O arquivo /about/index.html	`200`	/sobre
/sobre/	O arquivo /about/index.html	`200`	/sobre/
/about/index.html	O arquivo /about/index.html	`200`	/about/index.html
/contato	O arquivo /contact.html	`200`	/contato
/contato/	O arquivo /contact.html	`301`	/contato
/contact.html	O arquivo /contact.html	`200`	/contact.html

Exemplo de ficheiro 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, analise os cenários a seguir.

Pedidos para...	resulta em...
/perfil	Os usuários autenticados recebem o arquivo /profile/index.html . Os usuários não autenticados são redirecionados para /login pela regra de substituição de `401` resposta.
/admin, /admin/, ou /admin/index.html	Os usuários autenticados na função de administrador recebem o arquivo /admin/index.html . Os usuários autenticados que não estão na função de administrador recebem um `403` erro¹. Os usuários não autenticados são redirecionados para /login
/imagens/logo.png	Serve a imagem com uma regra de cache personalizada onde a idade máxima é um pouco mais de 182 dias (15.770.000 segundos).
/api/admin	`GET` solicitações 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 de usuários registrados e os usuários não autenticados recebem um `401` erro. `POST`, `PUT`, `PATCH`, e `DELETE` solicitações de usuários autenticados na função de administrador são enviadas para a API. Os usuários autenticados que não estão na função de administrador e os usuários não autenticados recebem um `401` erro.
/clientes/contoso	Os usuários autenticados que pertencem às funções de administrador ou de customers_contoso recebem o arquivo /customers/contoso/index.html . Os usuários autenticados que não estão nas funções de administrador ou customers_contoso recebem um `403` erro¹. Os usuários não autenticados são redirecionados para /login.
/login	Os usuários não autenticados são desafiados a se autenticar com o GitHub.
/.auth/login/twitter	Como a autorização com o Twitter é desativada pela regra de rota, `404` o erro é retornado, que volta a servir /index.html com um código de `200` status.
/sair	Os usuários são desconectados de qualquer provedor de autenticação.
/calendário/2021/01	O navegador recebe o arquivo /calendar.html .
/especiais	O navegador é permanentemente redirecionado para /deals.
/data.json	O arquivo servido com o `text/json` tipo MIME.
/about, ou qualquer pasta que corresponda aos padrões de roteamento do lado do cliente	O arquivo /index.html é servido com um código de `200` status.
Um arquivo inexistente na pasta /images/	Um `404` erro.

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

Restrições

Existem as seguintes restrições para o ficheiro staticwebapp.config.json .

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

Consulte o artigo Cotas para restrições e limitações gerais.

Próximos passos

Configurar autenticação e autorização

Configurar Aplicativos Web Estáticos do Azure

Localização do ficheiro

Rotas

Definir rotas

Especificar padrões de rota

Rota exata

Padrão curinga

Rotas seguras com funções

Restringir o acesso a todo o aplicativo

Rotas de fallback

Cabeçalhos globais

Substituições de resposta

Plataforma

Selecione a versão do tempo de execução do idioma da API

.NET

Node.js

Python

Rede

Autenticação

Desativar cache para caminhos autenticados

Gateway de encaminhamento

Hosts encaminhados permitidos

Cabeçalhos obrigatórios

Barra à direita

Sempre

Nunca

Automático

Exemplo de ficheiro de configuração

Restrições

Próximos passos

Artigos relacionados

Recursos adicionais