Configuración de Azure Static Web Apps

Artículo
06/03/2024

Puede definir la configuración de Azure Static Web Apps en el archivo staticwebapp.config.json, que controla las opciones siguientes:

Enrutamiento
Autenticación
Autorización
Reglas de reserva
Respuesta HTTP invalida
Definiciones de encabezados HTTP globales
Tipos MIME personalizados
Redes

Nota:

El archivo routes.json que se usó anteriormente para configurar el enrutamiento está en desuso. Use staticwebapp.config.json como se describe en este artículo para configurar el enrutamiento y otras opciones para la aplicación web estática.

En este documento se describe cómo configurar Azure Static Web Apps, que es un producto independiente y independiente de la hospedaje de sitios web estáticos característica de Azure Storage.

Ubicación de los archivos

La ubicación recomendada del archivo staticwebapp.config.jsen es la carpeta establecida como app_location en el archivo de flujo de trabajo. Sin embargo, puede colocar el archivo en cualquier subcarpeta dentro de la carpeta establecida como la app_location. Además, si hay un paso de compilación, debe asegurarse de que el paso de compilación genera el archivo en la raíz del output_location.

Consulte el archivo de configuración de ejemplo para ver los detalles.

Importante

El archivo routes.json en desuso se omite si existe un archivo staticwebapp.config.json.

Rutas

Puede definir reglas para una o varias rutas en la aplicación web estática. Las reglas de ruta permiten restringir el acceso a los usuarios en roles específicos o realizar acciones como la redirección o la reescritura. Las rutas se definen como una matriz de reglas de enrutamiento. Consulte el archivo de configuración de ejemplo para ver cómo se usan.

Las reglas se definen en la matriz routes, aunque solo tenga una ruta.
Las reglas se evalúan en el orden en que aparecen en la matriz routes.
La evaluación de la regla se detiene en la primera coincidencia. Se produce una coincidencia cuando la propiedad route y un valor de la matriz methods (si se especifica) coinciden con la solicitud. Cada solicitud puede coincidir como máximo con una regla.

Los aspectos relacionados con el enrutamiento se superponen en buena parte a los conceptos de autenticación (identificación del usuario) y autorización (concesión de capacidades al usuario). Asegúrese de leer la guía de autenticación y autorización junto con este artículo.

Definición de rutas

Cada una se compone de un patrón de ruta, junto con una o varias de las propiedades de regla opcionales. Las reglas de ruta se definen en la matriz routes. Consulte el archivo de configuración de ejemplo para ver cómo se usan.

Importante

Solo se usan las propiedades route y methods (si se especifica) para determinar si una regla coincide con una solicitud.

Propiedad de regla	Obligatorio	Valor predeterminado	Comentario
`route`	Sí	N/D	Patrón de ruta solicitado por el autor de la llamada. Los caracteres comodín se admiten al final de las rutas. Por ejemplo, la ruta /admin* coincide con cualquier ruta que comience por /admin.
`methods`	No	Todos los métodos	Define una matriz de métodos de solicitud que coinciden con una ruta. Algunos de los métodos disponibles son: `GET`, `HEAD`, `POST`, `PUT`, `DELETE`, `CONNECT`, `OPTIONS`, `TRACE` y `PATCH`.
`rewrite`	No	N/D	Define el archivo o la ruta de acceso que devuelve la solicitud. Es mutuamente excluyente con las reglas `redirect` Las reglas de reescritura no cambian la ubicación del explorador. Los valores deben hacer referencia a la raíz de la aplicación.
`redirect`	No	N/D	Define el destino de redireccionamiento del archivo o la ruta de acceso de una solicitud. Es mutuamente excluyente con las reglas `rewrite` Las reglas de redireccionamiento cambian la ubicación del explorador. El código de respuesta predeterminado es `302` (redireccionamiento temporal), pero puede invalidarse con `301` (redirección permanente).
`statusCode`	No	`301` o `302` para las redirecciones	Código de estado HTTP de la respuesta.
`headers`	No	N/D	Conjunto de encabezados HTTP que se agregan a la respuesta. Los encabezados específicos de la ruta invalidan los encabezados `globalHeaders` cuando el encabezado específico de la ruta es igual que el encabezado global de la respuesta. Para quitar un encabezado, establezca el valor en una cadena vacía.
`allowedRoles`	No	anónimo	Define una matriz de nombres de rol necesarios para acceder a una ruta. Los caracteres válidos incluyen `a-z`, `A-Z`, `0-9` y `_`. El rol integrado, `anonymous`, se aplica a todos los usuarios. El rol integrado, `authenticated`, se aplica a todos los usuarios que han iniciado sesión. Los usuarios deben pertenecer al menos a un rol. Los roles se evalúan según el operador OR. Si un usuario tiene cualquiera de los roles enumerados, se le concede acceso. Los usuarios individuales se asocian a los roles a través de invitaciones.

Cada propiedad tiene un propósito específico en la canalización de solicitudes o respuestas.

Propósito	Propiedades
Establecer correspondencias en las rutas	`route`, `methods`
Realizar los procesos correspondientes una vez que se cumple y se autoriza una regla	`rewrite` (modifica la solicitud) `redirect`, `headers` y `statusCode` (modifica la respuesta)
Proporcionar autorización después de encontrar la correspondencia de una ruta	`allowedRoles`

Especificación de patrones de ruta

La propiedad route puede ser una ruta exacta o un patrón de caracteres comodín.

Ruta exacta

Para definir una ruta exacta, coloque la ruta de acceso completa del archivo en la propiedad route.

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

Esta regla coincide con las solicitudes del archivo /profile/index.html. Como index.html es el archivo predeterminado, la regla también coincide con las solicitudes de la carpeta (/profile o /profile/).

Importante

Si usa una ruta de acceso de carpeta (/profile o /profile/) en la propiedad route, no coincidirá con las solicitudes del archivo /profile/index.html. Al proteger una ruta que sirve a un archivo, use siempre la ruta de acceso completa del archivo, como /profile/index.html.

Patrón de caracteres comodín

Las reglas de caracteres comodín coinciden con todas las solicitudes de un patrón de ruta y solo se admiten al final de una ruta de acceso. Consulte el archivo de configuración de ejemplo para ver cómo se usan.

Por ejemplo, si desea implementar las rutas de una aplicación de calendario, puede reescribir todas las direcciones URL que se encuentran en la ruta de calendar para que proporcionen un único archivo.

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

El archivo calendar.html puede usar el enrutamiento del lado cliente para generar una vista diferente para las variantes de las direcciones URL, como /calendar/january/1, /calendar/2020 y /calendar/overview.

Nota:

Un patrón de ruta de /calendar/* coincide con todas las solicitudes en la ruta de acceso /calendar/. Sin embargo, no coincidirá con las solicitudes de las rutas de acceso /calendar o /calendar.html. Use /calendar* para que coincida con todas las solicitudes que comienzan por /calendar.

Puede filtrar las coincidencias con caracteres comodín por la extensión de archivo. Por ejemplo, si desea agregar una regla que solo coincida con los archivos HTML de una ruta de acceso determinada, puede crear la siguiente regla:

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

Para filtrar por varias extensiones de archivo, incluya las opciones entre llaves, tal y como se muestra en este ejemplo:

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

Algunos de los casos de uso de las rutas con caracteres comodín más frecuentes son:

Proporcionar un archivo específico para todo un patrón de rutas de acceso
Aplicar reglas de autenticación y autorización
Implementar reglas de almacenamiento en caché especializadas

Protección de rutas mediante roles

Las rutas están protegidas mediante la adición de uno o varios nombres de rol a la matriz allowedRoles de una regla. Consulte el archivo de configuración de ejemplo para ver cómo se usan.

Importante

Las reglas de enrutamiento solo pueden proteger las solicitudes HTTP a las rutas que se sirven desde Static Web Apps. Muchos marcos de front-end usan el enrutamiento del lado cliente que modifica las rutas en el explorador sin emitir solicitudes a Static Web Apps. Las reglas de enrutamiento no protegen las rutas del lado cliente. Los clientes deben llamar a las API HTTP para recuperar datos confidenciales. Asegúrese de que las API validen la identidad de un usuario antes de devolver los datos.

De forma predeterminada, todos los usuarios pertenecen al rol de anonymous integrado, y todos los usuarios que han iniciado sesión son miembros del rol authenticated. Opcionalmente, los usuarios están asociados a roles personalizados a través de invitaciones.

Por ejemplo, para restringir una ruta solo a los usuarios autenticados, agregue el rol authenticated integrado a la matriz allowedRoles.

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

Puede crear nuevos roles según sea necesario en la matriz allowedRoles. Para restringir una ruta exclusivamente a los administradores, puede definir un rol propio llamado administrator en la matriz allowedRoles.

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

Tiene control total sobre los nombres de rol, ya que no hay ninguna lista que los roles deban seguir.
Los usuarios individuales se asocian a los roles a través de invitaciones.

Importante

Al proteger el contenido, especifique los archivos exactos cuando sea posible. Si tiene muchos archivos para proteger, use caracteres comodín después de un prefijo compartido. Por ejemplo: /profile* protege todas las rutas posibles que comienzan por /profile, incluido /profile.

Restricción del acceso a toda una aplicación

A menudo le conviene requerir autenticación para cada ruta de la aplicación. Para bloquear las rutas, agregue una regla que coincida con todas las rutas e incluya el rol integrado authenticated en la matriz de allowedRoles.

En la siguiente configuración de ejemplo se bloquea el acceso anónimo y se redirigen todos los usuarios no autenticados a la página de inicio de sesión de Microsoft Entra.

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

Nota:

De forma predeterminada, todos los proveedores de identidades preconfigurados están habilitados. Para bloquear un proveedor de autenticación, consulte Autenticación y autorización.

Rutas de reserva

Las aplicaciones de una sola página suelen utilizar el enrutamiento del lado cliente. Estas reglas de enrutamiento del lado cliente actualizan la ubicación de la ventana del explorador sin realizar solicitudes al servidor. Si actualiza la página o va directamente a direcciones URL generadas por reglas de enrutamiento del lado cliente, se requiere una ruta de reserva del lado servidor para atender la página HTML adecuada. La página de reserva se suele designar como index.html para la aplicación del lado cliente.

Nota:

Las reglas de ruta no se aplican en las solicitudes que desencadenan navigationFallback.

Puede definir una regla de reserva agregando una sección navigationFallback. En el siguiente ejemplo se devuelve /index.html para todas las solicitudes de archivos estáticos que no coinciden con un archivo implementado.

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

Puede controlar qué solicitudes devuelven el archivo de reserva definiendo un filtro. En el siguiente ejemplo, las solicitudes de determinadas rutas en la carpeta /images y todos los archivos de la carpeta /css están excluidos de la devolución del archivo de reserva.

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

Por ejemplo, con la siguiente estructura de directorios, la regla de reserva de navegación anterior daría lugar a los resultados detallados en la tabla siguiente.

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

Enviar una solicitud a...	devuelve...	con el estado...
/about/	El archivo /index.html.	`200`
/images/logo.png	Archivo de imagen.	`200`
/images/icon.svg	El archivo /index.html, ya que la extensión de archivo svg no aparece en el filtro `/images/*.{png,jpg,gif}`.	`200`
/images/unknown.png	Error de archivo no encontrado.	`404`
/css/unknown.css	Error de archivo no encontrado.	`404`
/css/global.css	Archivo de hoja de estilos.	`200`
/about.html	Página HTML.	`200`
Cualquier otra ruta fuera de las carpetas /images o /css que no coincida con la ruta a un archivo implementado.	El archivo /index.html.	`200`

Importante

Si va a migrar desde el archivo routes.json en desuso, no incluya la ruta de reserva heredada ("route": "/*") en las reglas de enrutamiento.

Encabezados globales

En la sección globalHeaders se proporciona un conjunto con los encabezados HTTP que se aplican a cada respuesta, a menos que queden invalidados por una regla de encabezado de ruta. De lo contrario, se devuelve la unión de los dos encabezados de la ruta y los encabezados globales.

Consulte el archivo de configuración de ejemplo para ver cómo se usan.

Para quitar un encabezado, establezca el valor en una cadena vacía ("").

Algunos casos de uso comunes de los encabezados globales son:

Reglas de almacenamiento en caché personalizadas
Directivas de seguridad
Configuración de la codificación
Configuración de uso compartido de recursos entre orígenes (CORS)

En el ejemplo siguiente se implementa una configuración de CORS personalizada.

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

Nota:

Los encabezados globales no afectan a las respuestas de API. Los encabezados de las respuestas de API se conservan y se devuelven al cliente.

Invalidación de respuestas

En la sección responseOverrides, se puede definir una respuesta personalizada en lugar de que el servidor devuelva un código de error. Consulte el archivo de configuración de ejemplo para ver cómo se usan.

Los siguientes códigos HTTP se pueden reemplazar:

Código de estado	Significado	Causa posible
400	Solicitud incorrecta	Vínculo de invitación no válido
401	No autorizado	Solicitud a páginas restringidas mientras no se está autenticado
403	Prohibida	El usuario ha iniciado sesión, pero no tiene los roles necesarios para ver la página. El usuario ha iniciado sesión, pero el runtime no puede obtener los detalles del usuario a partir de sus notificaciones de identidad. Hay demasiados usuarios que han iniciado sesión en el sitio con roles personalizados, por lo que el runtime no puede iniciar la sesión del usuario.
404	No se ha encontrado	Archivo no encontrado

En la configuración del ejemplo siguiente, se muestra cómo invalidar un código de error.

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

Plataforma

La sección platform controla la configuración específica de la plataforma, como la versión del entorno de ejecución del lenguaje de API.

Selección de la versión de runtime del lenguaje de API

Para configurar la versión del entorno de ejecución del lenguaje de API, establezca la propiedad apiRuntime de la sección platform en uno de los siguientes valores admitidos.

Versión del entorno de ejecución del lenguaje	Sistema operativo	Versión de Azure Functions	Valor de `apiRuntime`	Fecha de finalización de soporte técnico
.NET Core 3.1	Windows	3.x	`dotnet:3.1`	3 de diciembre de 2022
.NET 6.0 en proceso	Windows	4.x	`dotnet:6.0`	-
.NET 6.0 aislado	Windows	4.x	`dotnet-isolated:6.0`	-
.NET 7.0 (aislado)	Windows	4.x	`dotnet-isolated:7.0`	-
Aislado de .NET 8.0	Windows	4.x	`dotnet-isolated:8.0`	-
Node.js 12.x	Linux	3.x	`node:12`	3 de diciembre 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`	-
Node.js 20.x (versión preliminar)	Linux	4.x	`node:20`	-
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 cambiar la versión en tiempo de ejecución en una aplicación .NET, cambie el valor TargetFramework del archivo csproj. Aunque es opcional, si establece un valor apiRuntime en el archivo staticwebapp.config.json, asegúrese de que coincida con lo que define en el archivo csproj.

En el ejemplo siguiente se muestra cómo actualizar el elemento TargetFramework para NET 8.0 como la versión del entorno de ejecución del lenguaje de API del archivo csproj.

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

Node.js

En la configuración de ejemplo siguiente, se muestra cómo usar la propiedad apiRuntime para seleccionar Node.js 16 como la versión del entorno de ejecución del lenguaje de API del archivo staticwebapp.config..json.

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

Python

En la siguiente configuración de ejemplo se muestra cómo usar la propiedad apiRuntime para seleccionar Python 3.8 como la versión del entorno de ejecución del lenguaje de API del archivo staticwebapp.config.json.

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

Redes

La sección networking controla la configuración de red de su aplicación web estática. Para restringir el acceso a su aplicación, especifique una lista de bloques de direcciones IP permitidos en allowedIpRanges. Para más información sobre el número de bloques de direcciones IP permitidos, consulte Cuotas en Azure Static Web Apps.

Nota:

La configuración de red solo está disponible en el plan Estándar de Azure Static Web Apps.

Defina cada bloque de direcciones IPv4 en la notación Enrutamiento de interdominios sin clases (CIDR). Para más información acerca de la notación CIDR, consulte Enrutamiento de interdominios sin clases. Cada bloque de direcciones IPv4 puede indicar un espacio de direcciones público o privado. Si solo desea permitir el acceso desde una sola dirección IP, puede usar el bloque CIDR /32.

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

Cuando se especifican uno o más bloques de direcciones IP, se deniega el acceso a las solicitudes que se originan en direcciones IP que no coinciden con un valor en allowedIpRanges.

Además de los bloques de direcciones IP, también puede especificar etiquetas de servicio en la matriz allowedIpRanges para restringir el tráfico a determinados servicios de Azure.

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

Autenticación

Proveedores de autenticación predeterminados no requieren opciones en el archivo de configuración.
Los proveedores de autenticación personalizados usan la sección auth del archivo de configuración.

Para obtener más información sobre cómo restringir las rutas a los usuarios autenticados, consulte Protección de rutas mediante roles.

Deshabilitación de la caché para las rutas de acceso autenticadas

Si ha habilitado la integración manual con Azure Front Door, debería deshabilitar el almacenamiento en caché para las rutas protegidas. Con el perímetro de nivel empresarial habilitado, el almacenamiento en caché ya está deshabilitado para las rutas protegidas.

Para deshabilitar el almacenamiento en caché de Azure Front Door de rutas protegidas, agregue "Cache-Control": "no-store" a la definición del encabezado de ruta.

Por ejemplo:

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

Puerta de enlace de reenvío

En la sección forwardingGateway se configura cómo se accede a una aplicación web estática desde una puerta de enlace de reenvío, como Content Delivery Network (CDN) o Azure Front Door.

Nota:

La configuración de la puerta de enlace de reenvío solo está disponible en el plan estándar de Azure Static Web Apps.

Hosts reenviados permitidos

La lista allowedForwardedHosts especifica qué nombres de host se aceptan en el encabezado X-Forwarded-Host. Si un dominio que coincide está en la lista, Static Web Apps usa el valor X-Forwarded-Host al construir direcciones URL de redireccionamiento, por ejemplo, después de realizar un inicio de sesión correcto.

Para que Static Web Apps funcione correctamente detrás de una puerta de enlace de reenvío, la solicitud de la puerta de enlace debe incluir el nombre de host correcto en el encabezado X-Forwarded-Host y el mismo nombre de host debe aparecer enumerado en allowedForwardedHosts.

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

Si el encabezado X-Forwarded-Host no coincide con un valor de la lista, las solicitudes siguen siendo correctas, pero el encabezado no se usa en la respuesta.

Encabezados obligatorios

Los encabezados obligatorios son encabezados HTTP que se deben enviar con cada solicitud al sitio. Un uso de los encabezados necesarios es denegar el acceso a un sitio a menos que todos los encabezados necesarios estén presentes en cada solicitud.

Por ejemplo, la configuración siguiente muestra cómo puede agregar un identificador único para Azure Front Door que limite el acceso al sitio desde una instancia de Azure Front Door específica. Consulte el tutorial de configuración de Azure Front Door para obtener todos los detalles.

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

Los pares clave-valor pueden ser cualquier conjunto de cadenas arbitrarias.
Las claves no distinguen mayúsculas de minúsculas.
Los valores distinguen mayúsculas de minúsculas

Barra diagonal final

Una barra diagonal final es el carácter / al final de una dirección URL. Convencionalmente, una URL con una barra diagonal al final hace referencia a un directorio del servidor web, mientras que una URL sin barra diagonal indica un archivo.

Los motores de búsqueda tratan las dos direcciones URL por separado, con independencia de si es un archivo o un directorio. Cuando el mismo contenido se representa en ambas direcciones URL, su sitio web sirve contenido duplicado, lo que puede afectar negativamente a la optimización del motor de búsqueda (SEO). Cuando se configura explícitamente, Static Web Apps aplica un conjunto de reglas de normalización y redirección de direcciones URL que ayudan a mejorar el rendimiento y el SEO de su sitio web.

Las siguientes reglas de normalización y redirección se aplicarán a cada una de las configuraciones disponibles:

Siempre

Al establecer trailingSlash en always, todas las solicitudes que no incluyen una barra diagonal final se redirigen a una dirección URL con barra diagonal final. Por ejemplo, /contact se redirigirá a /contact/.

"trailingSlash": "always"

Enviar una solicitud a...	devuelve...	con el estado...	y la ruta de acceso...
/about	El archivo /about/index.html	`301`	/about/
/about/	El archivo /about/index.html	`200`	/about/
/about/index.html	El archivo /about/index.html	`301`	/about/
/privacy.html	El archivo /privacy.html	`301`	/privacy/

Nunca

Al establecer trailingSlash en never, todas las solicitudes que terminan en una barra diagonal final se redirigen a una dirección URL de barra diagonal sin límite. Por ejemplo, /contact/ se redirigirá a /contact.

"trailingSlash": "never"

Enviar una solicitud a...	devuelve...	con el estado...	y la ruta de acceso...
/about	El archivo /about/index.html	`200`	/about
/about/	El archivo /about/index.html	`301`	/about
/about/index.html	El archivo /about/index.html	`301`	/about
/privacy.html	El archivo /privacy.html	`301`	/privacy

Automático

Al establecer trailingSlash en auto, todas las solicitudes a carpetas se redirigen a una dirección URL con una barra diagonal final. Todas las solicitudes a los archivos se redirigen a una dirección URL de barra diagonal sin límite.

"trailingSlash": "auto"

Enviar una solicitud a...	devuelve...	con el estado...	y la ruta de acceso...
/about	El archivo /about/index.html	`301`	/about/
/about/	El archivo /about/index.html	`200`	/about/
/about/index.html	El archivo /about/index.html	`301`	/about/
/privacy.html	El archivo /privacy.html	`301`	/privacy

Para conseguir un rendimiento óptimo del sitio web, configure una estrategia de barra diagonal final mediante uno de estos modos: always, never o auto.

De forma predeterminada, cuando se omite la configuración de trailingSlash, Static Web Apps aplica las reglas siguientes:

Enviar una solicitud a...	devuelve...	con el estado...	y la ruta de acceso...
/about	El archivo /about/index.html	`200`	/about
/about/	El archivo /about/index.html	`200`	/about/
/about/index.html	El archivo /about/index.html	`200`	/about/index.html
/privacy.html	El archivo /privacy.html	`200`	/privacy.html

Ejemplo de archivo de configuración

{
  "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"
  }
}

Consulte los escenarios siguientes teniendo en cuenta la configuración anterior.

Enviar una solicitud a...	el resultado es...
/profile	Los usuarios autenticados reciban el archivo /profile/index.html. Los usuarios sin autenticar son redirigidos a /login por la regla de invalidación de respuestas `401`.
/admin, /admin/ o /admin/index.html	Se proporciona el archivo /admin/reports/index.html a los usuarios autenticados con el rol administrator. Los usuarios autenticados que no tienen el rol administrator reciben un error`403`.¹ Los usuarios sin autenticar son redirigidos a /login.
/images/logo.png	Proporciona a la imagen una regla de caché personalizada en la que la antigüedad máxima es un poco superior a 182 días (15 770 000 segundos).
/api/admin	Las solicitudes `GET` de los usuarios autenticados con el rol registeredusers se envían a la API. Los usuarios autenticados que no tienen el rol registeredusers y los que no se han autenticado reciben un error `401`. Las solicitudes `POST`, `PUT`, `PATCH` y `DELETE` de los usuarios autenticados con el rol administrator se envían a la API. Los usuarios autenticados que no tienen el rol administrator y los que no se han autenticado reciben un error `401`.
/customers/contoso	Los usuarios autenticados que pertenecen a los roles Administrador o customers_contoso reciben el archivo /customers/contoso/index.html. Los usuarios autenticados que no tienen los roles Administrador o customers_contoso reciben un error `403`¹. Los usuarios sin autenticar acceden automáticamente a /login.
/login	Se pide a los usuarios sin autenticar que lo hagan con GitHub.
_/.auth/login/x	Dado que la regla de ruta deshabilita la autorización de X, se devuelve un error de `404`. Este error vuelve a servir /index.html con un código de estado de `200`.
/logout	Se cierra la sesión de los usuarios con cualquier proveedor de autenticación.
/calendar/2021/01	El explorador proporciona el archivo /calendar.html.
/specials	El explorador accede de forma automática y permanente a /deals.
/data.json	El archivo se proporciona con el tipo MIME `text/json`.
/about o cualquier carpeta que coincida con los patrones de enrutamiento del lado cliente	El archivo /index.html se proporciona con el código de estado `200`.
Un archivo inexistente en la carpeta /images/	Error `404`.

¹ Puede proporcionar una página de error personalizada utilizando una regla de invalidación de respuestas.

Restricciones

El archivo staticwebapps.config.json tiene las siguientes restricciones.

El tamaño máximo del archivo es 20 KB.
Hay 50 roles distintos como máximo.

Vea el artículo sobre cuotas para conocer las restricciones y limitaciones generales.

Pasos siguientes

Configuración de la autenticación y autorización

Compartir a través de

Configuración de Azure Static Web Apps

Ubicación de los archivos

Rutas

Definición de rutas

Especificación de patrones de ruta

Ruta exacta

Patrón de caracteres comodín

Protección de rutas mediante roles

Restricción del acceso a toda una aplicación

Rutas de reserva

Encabezados globales

Invalidación de respuestas

Plataforma

Selección de la versión de runtime del lenguaje de API

.NET

Node.js

Python

Redes

Autenticación

Deshabilitación de la caché para las rutas de acceso autenticadas

Puerta de enlace de reenvío

Hosts reenviados permitidos

Encabezados obligatorios

Barra diagonal final

Siempre

Nunca

Automático

Ejemplo de archivo de configuración

Restricciones

Pasos siguientes

Comentarios

Recursos adicionales

Compartir a través de

Configuración de Azure Static Web Apps

Ubicación de los archivos

Rutas

Definición de rutas

Especificación de patrones de ruta

Ruta exacta

Patrón de caracteres comodín

Protección de rutas mediante roles

Restricción del acceso a toda una aplicación

Rutas de reserva

Encabezados globales

Invalidación de respuestas

Plataforma

Selección de la versión de runtime del lenguaje de API

.NET

Node.js

Python

Redes

Autenticación

Deshabilitación de la caché para las rutas de acceso autenticadas

Puerta de enlace de reenvío

Hosts reenviados permitidos

Encabezados obligatorios

Barra diagonal final

Siempre

Nunca

Automático

Ejemplo de archivo de configuración

Restricciones

Pasos siguientes

Artículos relacionados

Comentarios

Recursos adicionales