Configurar Aplicativos Web Estáticos do Azure

2025-04-01

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
Conetividade

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 ficheiro 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 propriedade route e um valor na methods (se especificado) correspondem à 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 rota routes são definidas na matriz. Consulte o ficheiro 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 de Regra	Necessário	Valor predefinido	Comentário
`route`	Sim	n/d	O padrão de rota solicitado pelo chamador. Os curingas são suportados no final das rotas. 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`, `OPTIONSTRACE`, e `PATCH`.
`rewrite`	Não	n/d	Define o arquivo ou caminho retornado da solicitação. É mutuamente exclusivo em relação a uma `redirect` regra. As regras de reescrita não alteram a localização do navegador. Os valores devem ser relativos à raiz do aplicativo.
`redirect`	Não	n/d	Define o destino de redirecionamento de um 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`	Não	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 é igual ao cabeçalho global 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 utilizadores. A função interna, `authenticated`, aplica-se a qualquer utilizador que tenha iniciado sessão. Os usuários devem pertencer a pelo menos uma função. As funções são correspondidas com base em OU. 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 fluxo 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 de uma rota ser confirmada	`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 cliente para servir uma exibição diferente para variações de URL como /calendar/january/1, /calendar/2020 e /calendar/overview.

Nota

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 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 todo um padrão de caminho
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 ao adicionar um ou mais nomes de função à matriz de uma regra allowedRoles. 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. Muitos frameworks front-end usam roteamento cliente que modifica rotas no navegador sem emitir solicitações para Aplicações Web Estáticas. 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á lista à qual as suas funções devam seguir.
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 tiveres muitos arquivos para garantir a segurança, usa asteriscos após um prefixo comum. 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ê deseja exigir autenticação para cada rota em seu aplicativo. Para bloquear as suas rotas, adicione uma regra que corresponda a todas as rotas e inclua a função incorporada authenticated na allowedRoles lista.

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 Alternativas

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 atualizares a página ou navegares diretamente para URLs geradas por regras de encaminhamento no lado do cliente, uma rota de recurso no lado do servidor será necessária para entregar a página HTML apropriada. A página de fallback geralmente é designada como index.html para seu aplicativo do lado do cliente.

Nota

As regras de rota não são aplicadas em solicitações que acionam navigationFallback.

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
│
├── about.html
└── 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 ficheiro /index.html - já que a extensão svg não está listada no filtro `/images/*.{png,jpg,gif}`.	`200`
/imagens/unknown.png	Erro: arquivo não encontrado.	`404`
/css/unknown.css	Erro de arquivo não encontrado.	`404`
/css/global.css	O ficheiro de folha de estilo.	`200`
/about.html	A página HTML.	`200`
Qualquer outro caminho fora das pastas /images ou /css que não corresponda ao caminho para um arquivo implantado.	O arquivo /index.html.	`200`

Importante

Se estiver a migrar do ficheiro preterido routes.json, não inclua a rota de fallback herdada ("route": "/*") nas regras deroteamento.

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, será retornada a união dos cabeçalhos da rota e dos cabeçalhos globais.

Consulte o arquivo de exemplo de configuração para 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 para resposta

A seção responseOverrides fornece uma oportunidade para definir uma resposta personalizada quando, de outro modo, 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	Solicitação inválida	Link de convite inválido
401	Não autorizado	Solicitação para páginas restritas sem estar autenticado
403	Proibido	O usuário está conectado, mas não tem as funções necessárias para exibir a página. O utilizador está conectado, mas o runtime não pode obter os detalhes do utilizador a partir das suas reivindicações de identidade. Há muitos utilizadores conectados ao site com funções personalizadas; portanto, o sistema não consegue iniciar sessão no utilizador.
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 de runtime da linguagem da API

Para configurar a versão de tempo de execução da linguagem da API, defina a propriedade na secção apiRuntime para 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`	30 de abril de 2025
.NET 8.0 em processo	Windows	4.x	`dotnet:8.0`	-
.NET 6.0 isolado	Windows	4.x	`dotnet-isolated:6.0`	30 de abril de 2025
.NET 7.0 isolado	Windows	4.x	`dotnet-isolated:7.0`	30 de abril de 2025
.NET 8.0 isolado	Windows	4.x	`dotnet-isolated:8.0`	-
.NET 9.0 isolado	Windows	4.x	`dotnet-isolated:9.0`	-
Node.js 12.x	Linux	3.x	`node:12`	3 de dezembro de 2022
Node.js 14.x	Linux	4.x	`node:14`	30 de abril de 2025
Node.js 16.x	Linux	4.x	`node:16`	30 de abril de 2025
Node.js 18.x	Linux	4.x	`node:18`	31 de maio de 2025
Node.js 20.x	Linux	4.x	`node:20`	-
Python 3.8	Linux	4.x	`python:3.8`	30 de abril de 2025
Python 3,9	Linux	4.x	`python:3.9`	-
Python 3,10	Linux	4.x	`python:3.10`	-
Python 3.11	Linux	4.x	`python:3.11`	-

.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 elemento TargetFramework no NET 8.0 como a versão do runtime da linguagem 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 apiRuntime para selecionar o Node.js 16 como a versão da linguagem de tempo de execução 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 Quotas em Azure Static Web Apps.

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 tecnologia de ponta de nível empresarial habilitada, o cache já está desativado para as 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 retransmissão

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 permitidos encaminhados

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, as Aplicações Web Estáticas usarão o valor X-Forwarded-Host quando construírem URLs de redirecionamento, como após um início de sessão bem-sucedido.

Para que as Aplicações Web Estáticas funcionem corretamente atrás de um gateway de redirecionamento, é necessário que a solicitação do gateway inclua o nome de anfitrião correto no cabeçalho X-Forwarded-Host e que o mesmo nome de anfitrião esteja 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 são sensíveis a maiúsculas e minúsculas
Os valores diferenciam maiúsculas de minúsculas

Barra final

A barra no final é o / no final de um URL. Convencionalmente, um 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 do seu site e o desempenho de SEO.

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 final são redirecionados para um URL com uma barra final. Por exemplo, /contact é redirecionado para /contact/.

"trailingSlash": "always"

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

Nunca

Ao definir trailingSlash para never, todas as solicitações que terminam com uma barra no final são redirecionadas para uma URL sem barra no final. 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 ficheiro /about/index.html	`301`	/sobre
/about/index.html	O arquivo /about/index.html	`301`	/sobre
/privacy.html	O arquivo /privacy.html	`301`	/privacidade

Automático

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

"trailingSlash": "auto"

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

Para obter um desempenho ideal do site, defina uma estratégia de barra de URL usando um dos modos always, never ou 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
/privacy.html	O arquivo /privacy.html	`200`	/privacy.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/x",
      "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 utilizadores 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 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 utilizadores autenticados que pertencem às funções de administrador ou customers_contoso são direcionados para o ficheiro /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/x	Como a regra de rota desabilita a autorização X, um `404` erro é retornado. Em seguida, esse erro 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 ficheiro foi servido 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 é servido com um código de `200` status.
Um arquivo inexistente na pasta /images/	Um `404` erro.

¹ 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 limitações e restrições gerais.

Próximos passos

Configurar autenticação e autorização

Partilhar via

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 Alternativas

Cabeçalhos globais

Substituições para resposta

Plataforma

Selecione a versão de runtime da linguagem da API

.NET

Node.js

Python

Rede

Autenticação

Desativar cache para caminhos autenticados

Gateway de retransmissão

Hosts permitidos encaminhados

Cabeçalhos obrigatórios

Barra final

Sempre

Nunca

Automático

Exemplo de ficheiro de configuração

Restrições

Próximos passos

Artigos relacionados

Comentários

Recursos adicionais