Настройка Статических веб-приложений Azure

2024-05-24

Конфигурацию для Статические веб-приложения Azure можно определить в файле staticwebapp.config.json, который управляет следующими параметрами:

Маршрутизация
Аутентификация
Авторизация
Резервные правила
Переопределения ответа HTTP
Глобальные определения заголовков HTTP
Пользовательские типы MIME
Сеть

Примечание.

Файл routes.json, который ранее использовался для настройки маршрутизации, объявлен нерекомендуемым. Для настройки маршрутизации и других параметров вашего статического веб-приложения используйте файл staticwebapp.config.json, как описано в этой статье.

В этом документе описывается, как настроить Azure Static Web Apps, который является автономным продуктом и отделён от функции размещения статических веб-сайтов в службе Azure Storage.

Расположение файла

Мы рекомендуем размещать файл staticwebapp.config.json в папке, которая указана в качестве app_location в файле рабочего процесса. Однако файл можно поместить в любую вложенную папку в папке, заданной в качестве app_location. Кроме того, если есть шаг сборки, необходимо убедиться, что шаг сборки выводит файл в корневой каталог output_location.

Дополнительные сведения см. в примере файла конфигурации.

Внимание

Нерекомендуемый файл routes.json игнорируется, если существует файл staticwebapp.config.json.

Маршруты

Вы можете определить правила для одного или нескольких маршрутов в статическом веб-приложении. Правила маршрутизации позволяют ограничить доступ к пользователям в определенных ролях или выполнять такие действия, как перенаправление или перезапись. Маршруты определяются как массив правил маршрутизации. См. пример файла конфигурации для примеров использования.

Правила определяются в массиве routes, даже если имеется только один маршрут.
Правила оцениваются в порядке их отображения в массиве routes .
Оценка правила прекращается при первом совпадении. Совпадение происходит, когда route свойство и значение в массиве methods (если указано) соответствуют запросу. Каждый запрос может соответствовать по крайней мере одному правилу.

Вопросы маршрутизации в значительной степени связаны с такими понятиями, как проверка подлинности (идентификацией пользователя) и авторизация (назначению возможностей пользователю). При изучении этой статьи обязательно ознакомьтесь также с руководством по проверке подлинности и авторизации.

Определение маршрутов

Каждое правило состоит из шаблона маршрута, а также одного или нескольких необязательных свойств правила. Правила маршрута определяются в массиве routes. См. примере файла конфигурации для примеров использования.

Внимание

route и methods (если указано) — это единственные свойства, используемые для определения, соответствует ли правило запросу.

Свойство правила	Обязательное поле	Значение по умолчанию	Комментарий
`route`	Да	Н/Д	Шаблон маршрута, запрошенный звонившим. В концах маршрутов можно указывать подстановочные знаки. Например, маршрут /admin* соответствует любому маршруту, начиная с /admin.
`methods`	Нет	Все методы	Определяет массив методов запроса, соответствующих маршруту. Доступные методы: `GET`, `HEAD`, `POST`, `PUT`, `DELETE`, `CONNECT`, `OPTIONS`, `TRACE` и `PATCH`.
`rewrite`	Нет	Н/Д	Определяет файл или путь, возвращенные из запроса. Является взаимоисключающим с правилом `redirect`. Правила перезаписи не изменяют адрес в браузере. Значения должны быть относительно корневого каталога приложения.
`redirect`	Нет	Н/Д	Определяет цель перенаправления файла или пути в запросе. Является взаимоисключающим с правилом `rewrite`. Правила перенаправления изменяют адрес в браузере. По умолчанию используется код ответа `302` (временное перенаправление), но можно изменить на `301` (постоянное перенаправление).
`statusCode`	Нет	`301` или `302` для перенаправлений	Код состояния HTTP для ответа.
`headers`	Нет	Н/Д	Набор заголовков HTTP, которые добавляются в ответ. Заголовки, специфичные для маршрута, переопределяют значение `globalHeaders`, если заголовки маршрута совпадают с глобальными заголовками в ответе. Чтобы удалить заголовок, задайте в качестве значения пустую строку.
`allowedRoles`	Нет	анонимный	Определяет массив имен ролей, необходимых для доступа к маршруту. Допустимые символы: `a-z`, `A-Z`, `0-9` и `_`. Встроенная роль `anonymous`применяется ко всем пользователям. Встроенная роль `authenticated` применяется к любому пользователю, вошедшему в систему. Пользователи должны принадлежать по крайней мере к одной роли. Роли сопоставляются с использованием логического оператора ИЛИ. Если пользователю присвоена одна из перечисленных ролей, то доступ предоставляется. Отдельные пользователи связываются с ролями с помощью приглашений.

Каждое свойство имеет определенное назначение в процессе взаимодействия запроса и ответа.

Цель	Свойства
Сопоставление маршрутов	`route`, `methods`
Процесс, выполняемый после сопоставления и авторизации правила.	`rewrite` (изменяет запрос). `redirect`, `headers`, `statusCode` (изменяет ответ).
Авторизация после сопоставления маршрута.	`allowedRoles`

Определение шаблонов маршрутов

Свойство route может быть точным маршрутом или шаблоном с подстановочными символами.

Точный маршрут

Чтобы определить точный маршрут, поместите полный путь файла в route свойство.

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

Это правило соответствует запросам файла /profile/index.html. Так как index.html является файлом по умолчанию, правило также соответствует запросам к папке (/profile или /profile/).

Внимание

Если вы используете путь к папке (/profile или /profile/) в свойстве route , он не будет соответствовать запросам файла /profile/index.html. При защите маршрута, который служит файлом, всегда используйте полный путь к файлу, например /profile/index.html.

Шаблон подстановочного знака

Правила подстановочных знаков соответствуют всем запросам в шаблоне маршрута и поддерживаются только в конце пути. Для примеров использования см. пример файла конфигурации.

Например, для реализации маршрутов в приложении календаря можно перенаправить все URL-адреса, соответствующие маршруту calendar, к одному файлу.

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

Тогда файл calendar.html может использовать маршрутизацию на стороне клиента для предоставления разных представлений для различных вариантов URL-адресов, например /calendar/january/1, /calendar/2020 и /calendar/overview.

Примечание.

Шаблон маршрута /calendar/* соответствует всем запросам по пути /calendar/. Однако он не будет соответствовать запросам путей /calendar или /calendar.html. Используется /calendar* для сопоставления всех запросов, начинающихся с /calendar.

Вы можете фильтровать совпадения с подстановочными знаками по расширению файла. Например, можно добавить правило, которое соответствует только HTML-файлам по указанному пути:

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

Чтобы фильтровать совпадения по нескольким расширениям файлов, перечислите все нужные варианты в фигурных скобках, как в следующем примере:

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

Распространенные случаи использования маршрутов с подстановочными знаками включают:

предоставление конкретного файла для всего шаблона пути
применение правил проверки подлинности и авторизации;
Реализация специализированных правил кэширования

Защита маршрутов с помощью ролей

Маршруты защищаются путем добавления одного или нескольких имен ролей в массив allowedRoles правила. См. образец файла конфигурации для примеров использования.

Внимание

Правила маршрутизации могут только защищать HTTP-запросы к маршрутам, которые обслуживаются Статическими веб-приложениями. Многие frontend-фреймворки используют клиентскую маршрутизацию, которая изменяет маршруты в браузере без обращения к статическим веб-приложениям. Правила маршрутизации не защищают клиентские маршруты. Клиенты должны вызывать API HTTP для получения конфиденциальных данных. Убедитесь, что API проверяют удостоверение пользователя перед возвратом данных.

По умолчанию каждый пользователь принадлежит к встроенной роли anonymous, а все вошедшие в систему пользователи являются членами роли authenticated. При необходимости пользователи связываются с настраиваемыми ролями с помощью приглашений.

Например, чтобы ограничить маршрут только пользователями, прошедшими проверку подлинности, добавьте встроенную роль authenticated в массив allowedRoles.

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

При необходимости в массиве allowedRoles можно создать новые роли. Чтобы маршрут был доступен только администраторам, можно определить собственную роль administrator в массиве allowedRoles.

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

Вы можете выбрать любые имена ролей; не существует никаких обязательных списков.
Отдельные пользователи связываются с ролями с помощью приглашений.

Внимание

При защите содержимого укажите точные файлы, когда это возможно. Если у вас много файлов для защиты, используйте подстановочные знаки после общего префикса. Например: /profile* защищает все возможные маршруты, начинающиеся с /profile, включая /profile.

Ограничение доступа ко всему приложению

Часто требуется проверка подлинности для каждого маршрута в приложении. Чтобы заблокировать маршруты, добавьте правило, подходящее для всех маршрутов, и включите встроенную authenticated роль в allowedRoles массив.

В следующем примере конфигурации блокируется анонимный доступ и перенаправляет всех пользователей, не прошедших проверку подлинности, на страницу входа Microsoft Entra.

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

Примечание.

По умолчанию все предварительно настроенные поставщики удостоверений включены. Сведения о блокировке поставщика проверки подлинности см. в разделе "Проверка подлинности и авторизация".

Резервные маршруты

Одностраничные приложения часто используют маршрутизацию на стороне клиента. Эти правила маршрутизации на стороне клиента обновляют расположение окна в браузере без отправки обратных запросов на сервер. Если вы обновляете страницу или переходите непосредственно к URL-адресам, созданным правилами маршрутизации на стороне клиента, для обслуживания соответствующей HTML-страницы требуется резервный маршрут на стороне сервера. Резервная страница часто обозначается как index.html для клиентского приложения.

Примечание.

Правила маршрутизации не применяются к запросам, которые вызывают navigationFallback.

Вы можете определить резервное правило, добавив раздел navigationFallback. В следующем примере возвращается /index.html для всех статических запросов файлов, которые не соответствуют развернутому файлу.

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

Вы можете контролировать, какие запросы возвращают резервный файл, определяя фильтр. В следующем примере запросы для определенных маршрутов в папке /Images и все файлы в папке /css исключены из процесса возврата резервного файла.

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

Например, со следующей структурой каталогов, вышеуказанное резервное правило навигации приведет к результатам, описанным в следующей таблице.

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

Запросы на...	возвращает	со статусом
/about/	Файл /index.html.	`200`
/images/logo.png	Файл изображения.	`200`
/images/icon.svg	Файл /index.html — так как расширение svg-файла не указано в фильтре`/images/*.{png,jpg,gif}`.	`200`
/images/unknown.png	Ошибка: файл не найден.	`404`
/css/unknown.css	Файл не найден.	`404`
/css/global.css	Файл таблицы стилей.	`200`
/about.html	HTML-страница.	`200`
Любой другой путь за пределами папок /images или /css, который не соответствует пути к файлу после развертывания.	Файл /index.html.	`200`

Внимание

При переходе с устаревшего файла routes.json не используйте резервный маршрут прежних версий ("route": "/*") в правиле маршрутизации.

Глобальные заголовки

В globalHeaders этом разделе содержится набор заголовков HTTP, применяемых к каждому ответу, если не переопределяется правилом заголовков маршрута, в противном случае возвращается объединение заголовков из маршрута и глобальных заголовков.

См. пример файла конфигурации для примеров использования.

Чтобы удалить заголовок, задайте в качестве значения пустую строку ("").

Ниже приведены типичные примеры использования глобальных заголовков.

Настраиваемые правила кэширования
Политики безопасности
Параметры кодирования
Конфигурация общего доступа к ресурсам между источниками (CORS)

В следующем примере реализована настраиваемая конфигурация CORS.

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

Примечание.

Глобальные заголовки не влияют на ответы API. Заголовки в ответах API сохраняются и возвращаются клиенту.

Переопределения ответов системой

Раздел responseOverrides позволяет определить пользовательский ответ для ситуаций, в которых сервер иначе возвращал бы код ошибки. См. пример файла конфигурации для примеров использования.

Для переопределения доступны следующие коды HTTP.

Код состояния	Значение	Возможная причина
400	Недопустимый запрос	Недействительная ссылка приглашения.
401	Не авторизовано	Запрос к страницам с ограничением доступа без проверки подлинности.
403	Запрещено	Пользователь вошел в систему, но не имеет необходимых ролей для просмотра этой страницы. Пользователь вошел в систему, но среда выполнения не может получить сведения о пользователе из удостоверяющих данных. На сайте слишком много пользователей, вошло с настраиваемыми ролями, поэтому система не может авторизовать пользователя.
404	Не найдено	Файл не найден

В следующем примере конфигурации показано, как переопределить код ошибки.

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

Платформа

Раздел platform управляет определенными параметрами платформы, такими как версия среды выполнения языка API.

Выбор версии среды выполнения языка API

Чтобы настроить версию среды выполнения языка API, задайте apiRuntime для свойства в platform разделе одно из следующих поддерживаемых значений.

Версия среды выполнения языка	Операционная система	Версия для Функций Azure	Значение `apiRuntime`	Дата окончания поддержки
.NET Core 3.1.	Windows	3.x	`dotnet:3.1`	3 декабря 2022 г.
В процессе .NET 6.0	Windows	4.x	`dotnet:6.0`	30 апреля 2025 г.
Встроенная .NET 8.0	Windows	4.x	`dotnet:8.0`	-
Изолированный .NET 6.0	Windows	4.x	`dotnet-isolated:6.0`	30 апреля 2025 г.
Изолированный .NET 7.0	Windows	4.x	`dotnet-isolated:7.0`	30 апреля 2025 г.
Изолированная версия .NET 8.0	Windows	4.x	`dotnet-isolated:8.0`	-
.NET 9.0 изолированный	Windows	4.x	`dotnet-isolated:9.0`	-
Node.js 12.x	Linux	3.x	`node:12`	3 декабря 2022 г.
Node.js 14.x	Linux	4.x	`node:14`	30 апреля 2025 г.
Node.js 16.x	Linux	4.x	`node:16`	30 апреля 2025 г.
Node.js 18.x	Linux	4.x	`node:18`	31 мая 2025 г.
Node.js 20.x	Linux	4.x	`node:20`	-
Python 3.8	Linux	4.x	`python:3.8`	30 апреля 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

Чтобы изменить версию среды выполнения в приложении .NET, измените TargetFramework значение в csproj-файле . Хотя это необязательно, если вы задаёте значение apiRuntime в файле staticwebapp.config.json, убедитесь, что оно соответствует значению, указанному в csproj-файле.

В следующем примере показано, как обновить TargetFramework элемент для NET 8.0 в качестве версии среды выполнения языка API в csproj-файле .

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

Node.js

В следующем примере конфигурации показано, как использовать apiRuntime свойство для выбора Node.js 16 в качестве версии среды выполнения языка API в файле staticwebapp.config.json .

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

Python

В следующем примере конфигурации показано, как использовать apiRuntime свойство для выбора Python 3.8 в качестве версии среды выполнения языка API в файле staticwebapp.config.json .

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

Сеть

Раздел networking управляет конфигурацией сети статического веб-приложения. Чтобы ограничить доступ к приложению, укажите список разрешенных блоков IP-адресов в allowedIpRanges. Дополнительные сведения о количестве разрешенных блоков IP-адресов см. в разделе «Квоты» в Azure Static Web Apps.

Примечание.

Конфигурация сети доступна только в плане Standard продукта Azure Static Web Apps.

Определите каждый блок адресов IPv4 в нотации бесклассовой междоменной маршрутизации (CIDR). Подробная информация о нотации CIDR приведена в разделе Бесклассовая междоменная маршрутизация. Каждый блок адресов IPv4 может обозначать либо общедоступный, либо частный диапазон адресов. Если вы хотите разрешить доступ только из одного IP-адреса, можно использовать /32 блок CIDR.

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

Если указан один или несколько блоков IP-адресов, доступ для запросов, исходящих из IP-адресов, которые не соответствуют значению в allowedIpRanges, запрещен.

Помимо блоков IP-адресов, можно также указать тегиallowedIpRangesтрафик определенным службам Azure.

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

Проверка подлинности

Поставщики проверки подлинности по умолчанию не требуют параметров в файле конфигурации.
Пользовательские поставщики проверки подлинности используют auth секцию файла настроек.

Дополнительные сведения о том, как ограничить маршруты для прошедших проверку подлинности пользователей, см. в разделе "Защита маршрутов с помощью ролей".

Отключение кэша для путей, прошедших проверку подлинности

Если вы настроили интеграцию вручную с Azure Front Door, может потребоваться отключить кэширование для защищенных маршрутов. С поддержкой периферийных вычислений корпоративного уровня кэширование уже отключено для защищенных маршрутов.

Чтобы отключить кэширование Azure Front Door для защищенных маршрутов, добавьте "Cache-Control": "no-store" в определение заголовка маршрута.

Например:

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

Шлюз для переадресации

Раздел forwardingGateway настраивает, как к статическим веб-приложениям осуществляется доступ через шлюз пересылки, например, через сеть доставки контента (CDN) или Azure Front Door.

Примечание.

Конфигурация шлюза пересылки доступна только в плане Azure Static Web Apps Standard.

Разрешенные переадресованные хосты

В списке allowedForwardedHosts указаны доменные имена, которые принимаются в заголовке X-Forwarded-Host. Если соответствующий домен находится в списке, Статические веб-приложения использует X-Forwarded-Host значение при создании URL-адресов перенаправления, например после успешного входа.

Чтобы статические веб-приложения правильно функционировали за шлюзом пересылки, запрос из шлюза должен содержать правильное имя узла в заголовкеX-Forwarded-Host, а имя узла должно быть указано в allowedForwardedHosts.

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

X-Forwarded-Host Если заголовок не соответствует значению в списке, запросы по-прежнему выполняются успешно, но заголовок не используется в ответе.

Обязательные заголовки

Обязательные заголовки — это заголовки HTTP, которые должны отправляться с каждым запросом на сайт. Одним из обязательных заголовков является запрет доступа к сайту, если все необходимые заголовки не присутствуют в каждом запросе.

Например, в следующей конфигурации показано, как добавить уникальный идентификатор Azure Front Door , который ограничивает доступ к сайту из определенного экземпляра Azure Front Door. Полные сведения см. в руководстве по настройке Azure Front Door.

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

Пары "ключ-значение" могут быть любым набором произвольных строк
Ключи являются нечувствительными к регистру
Значения чувствительны к регистру

Завершающая косая черта

Косая черта является / в конце URL-адреса. Как правило, URL с конечной косой чертой ссылается на каталог на веб-сервере, тогда как URL без конечной косой черты указывает на файл.

Поисковые системы обрабатывают два URL-адреса отдельно независимо от того, является ли он файлом или каталогом. При отображении одного содержимого на обоих из этих URL-адресов веб-сайт служит дубликатом содержимого, что может негативно повлиять на оптимизацию поисковой системы (SEO). При явной настройке Статические веб-приложения применяет набор правил нормализации URL-адресов и перенаправления, которые помогают повысить производительность веб-сайта и производительность SEO.

Для каждой доступной конфигурации применяются следующие правила нормализации и перенаправления:

Всегда

При настройке trailingSlash на always, все запросы, которые не включают завершающий слеш, перенаправляются на URL-адрес с завершающим слешем. Например, /contact перенаправляется в /contact/.

"trailingSlash": "always"

Запросы на...	возврат	Со статусом...	и путь...
/about	Файл /about/index.html	`301`	/about/
/about/	Файл /about/index.html	`200`	/about/
/about/index.html	Файл /about/index.html	`301`	/about/
/privacy.html	Файл /privacy.html	`301`	/конфиденциальность/

Никогда

При задании trailingSlash равным never, все запросы, заканчивающиеся косой чертой, перенаправляются на URL-адрес без косой черты. Например, /contact/ перенаправляется в /contact.

"trailingSlash": "never"

Запросы на...	возвраты	С статусом...	и путь...
/около	Файл /about/index.html	`200`	/about
/about/	Файл /about/index.html	`301`	/около
/about/index.html	Файл /about/index.html	`301`	/about
/privacy.html	Файл /privacy.html	`301`	/конфиденциальность

Авто

Когда вы устанавливаете trailingSlash в auto, все запросы к папкам перенаправляются на URL-адрес с завершающей косой чертой. Все запросы к файлам перенаправляются на URL-адрес без завершающей косой черты.

"trailingSlash": "auto"

Запросы на...	возвращает	с состоянием...	и путь...
/about	Файл /about/index.html	`301`	/about/
/about/	Файл /about/index.html	`200`	/about/
/about/index.html	Файл /about/index.html	`301`	/about/
/privacy.html	Файл /privacy.html	`301`	/конфиденциальность

Для оптимальной производительности веб-сайта настройте стратегию использования косой черты с помощью одного из режимов: always, never, или auto.

По умолчанию, если конфигурация trailingSlash опущена, Статические веб-приложения применяют следующие правила:

Запросы к...	возвращает	со статусом	и путь...
/about	Файл /about/index.html	`200`	/около
/about/	Файл /about/index.html	`200`	/about/
/about/index.html	Файл /about/index.html	`200`	/about/index.html
/privacy.html	Файл /privacy.html	`200`	/privacy.html

Пример файла конфигурации

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

Ознакомьтесь со следующими сценариями для приведенной выше конфигурации.

Запросы на...	Приводит к...
/profile	Для пользователей, прошедших проверку подлинности, передается файл /profile/index.html. Не прошедшие проверку подлинности пользователи перенаправляются на /login с помощью правила переопределения ответа `401`.
/admin, /admin/или /admin/index.html	Для пользователей, прошедших проверку подлинности в роли administrator, предоставляется файл /admin/index.html. Пользователи, прошедшие проверку подлинности, но не зарегистрированные в роли administrator, получают ошибку `403`¹. Пользователи, не прошедшие проверку подлинности, перенаправляются в /login
/images/logo.png	Возвращает изображение, для которого применяется пользовательское правило кэширования, определяющее максимальный срок чуть более 182 дней (15 770 000 секунд).
/api/admin	Запросы `GET` от пользователей, прошедших проверку подлинности, у которых есть роль registeredusers, отправляются в API. Аутентифицированные пользователи, не имеющие роли registeredusers, и неаутентифицированные пользователи получают ошибку `401`. Запросы `POST`, `PUT`, `PATCH` и `DELETE` от пользователей, прошедших проверку подлинности, у которых есть роль administrator, отправляются в API. Аутентифицированные пользователи, не имеющие роли administrator, и неаутентифицированные пользователи получают ошибку `401`.
/customers/contoso	Пользователям, прошедшим проверку подлинности и имеющим роль administrators или customers_contoso, предоставляется файл /customers/contoso/index.html. Пользователи, прошедшие проверку подлинности, но не имеющие роли administrators или customers_contoso, получают сообщение об ошибке `403`¹. Пользователи, не прошедшие проверку подлинности, перенаправляются на адрес /login.
/login	Пользователям, не прошедшим проверку подлинности, предлагается сделать это с помощью GitHub.
_/.auth/login/x	Поскольку правило маршрута отключает авторизацию X, `404` ошибка возвращается. Эта ошибка затем возвращается к обслуживанию /index.html с `200` кодом состояния.
/logout	Пользователи вышли из всех поставщиков проверки подлинности.
/calendar/2021/01	В браузер подаётся файл /calendar.html.
/specials	Браузер постоянно перенаправляется на /deals.
/data.json	Файл передается с MIME-типом `text/json`.
/about или любая другая папка, соответствующая шаблонам маршрутизации на стороне клиента.	Файл /index.html обслуживается с кодом статуса `200`.
Несуществующий файл в папке /images/	Ошибка `404`.

¹ Вы можете предоставлять настраиваемую страницу ошибки, используя правило переопределения ответа.

Ограничения

Для файла staticwebapp.config.json существуют следующие ограничения.

Максимальный размер файла составляет 20 КБ
Не более 50 различных ролей.

Общие ограничения см. в статье о квотах.

Следующие шаги

Настройка проверки подлинности и авторизации

Поделиться через

Настройка Статических веб-приложений Azure

Расположение файла

Маршруты

Определение маршрутов

Определение шаблонов маршрутов

Точный маршрут

Шаблон подстановочного знака

Защита маршрутов с помощью ролей

Ограничение доступа ко всему приложению

Резервные маршруты

Глобальные заголовки

Переопределения ответов системой

Платформа

Выбор версии среды выполнения языка API

.NET

Node.js

Python

Сеть

Проверка подлинности

Отключение кэша для путей, прошедших проверку подлинности

Шлюз для переадресации

Разрешенные переадресованные хосты

Обязательные заголовки

Завершающая косая черта

Всегда

Никогда

Авто

Пример файла конфигурации

Ограничения

Следующие шаги

Связанные статьи

Обратная связь

Дополнительные ресурсы