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

Статья
03/11/2023

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

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

Примечание.

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

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

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

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

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

Внимание

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

Маршруты

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

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

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

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

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

Внимание

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

Свойство правила	Обязательное поле	Default value	Comment
`route`	Да	Н/Д	Шаблон маршрута, запрошенный вызывающим объектом. В конце путей маршрутов можно указывать подстановочные знаки. Например, маршрут /admin* соответствует любому маршруту, начиная с /admin.
`methods`	No	Все методы	Определяет массив методов запроса, соответствующих маршруту. Доступные методы: `GET`, `HEAD`, `POST`, `PUT`, `DELETE`, `CONNECT`, `OPTIONS`, `TRACE` и `PATCH`.
`rewrite`	No	Н/Д	Определяет файл или путь, возвращенные из запроса. Является взаимоисключающим с правилом `redirect`. Правила перезаписи не изменяют адрес в браузере. Значения должны быть относительно корневого каталога приложения.
`redirect`	No	Н/Д	Определяет назначение перенаправления для файла или пути в запросе. Является взаимоисключающим с правилом `rewrite`. Правила перенаправления изменяют адрес в браузере. По умолчанию используется код ответа `302` (временное перенаправление), но можно изменить на `301` (постоянное перенаправление).
`statusCode`	No	`301` или `302` для перенаправлений	Код состояния HTTP для ответа.
`headers`	No	Н/Д	Набор заголовков HTTP, которые добавляются в ответ. Заголовки для конкретного маршрута переопределяют значение `globalHeaders`, если имена заголовков для конкретного маршрута и глобальных заголовков в ответе совпадают. Чтобы удалить заголовок, задайте в качестве значения пустую строку.
`allowedRoles`	No	анонимное	Определяет массив имен ролей, необходимых для доступа к маршруту. Допустимые символы: `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.

Шаблон Wild карта

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

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

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

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

Примечание.

Шаблон маршрута соответствует всем запросам /calendar/*в /calendar/ path. Однако он не будет соответствовать запросам путей /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-запросы к маршрутам, обслуживающимся из Статические веб-приложения. Многие интерфейсные платформы используют клиентская маршрутизация, которая изменяет маршруты в браузере без выдачи запросов на Статические веб-приложения. Правила маршрутизации не защищают клиентские маршруты. Клиенты должны вызывать 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. В следующем примере возвращается /index.html для всех статических запросов файлов, которые не соответствуют развернутого файла.

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

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

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

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

├── images
│   ├── logo.png
│   ├── headshot.jpg
│   └── screenshot.gif
│
├── css
│   └── global.css
│
└── 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`
Любой другой файл за пределами папок /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`	-
Изолированный .NET 6.0	Windows	4.x	`dotnet-isolated:6.0`	-
Изолированный .NET 7.0	Windows	4.x	`dotnet-isolated:7.0`	-
Изолированный .NET 8.0	Windows	4.x	`dotnet-isolated:8.0`	-
Node.js 12.x	Linux	3.x	`node:12`	3 декабря 2022 г.
Node.js 14.x	Linux	4.x	`node:14`	-
Node.js 16.x	Linux	4.x	`node:16`	-
Node.js 18.x (общедоступная предварительная версия)	Linux	4.x	`node:18`	-
Python 3.8	Linux	4.x	`python:3.8`	-
Python 3.9	Linux	4.x	`python:3.9`	-
Python 3.10	Linux	4.x	`python:3.10`	-

.NET

Чтобы изменить версию среды выполнения в приложении .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.

Примечание.

Конфигурация сети доступна только в плане "Стандартный" статических веб-приложений Azure.

Определите каждый блок адресов 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 "Стандартный".

Разрешенные переадресированные узлы

В списке 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-адресов веб-сайт служит дубликатом содержимого, что может негативно повлиять на оптимизацию поисковой системы (SEO). При явной настройке Статические веб-приложения применяет набор правил нормализации URL-адресов и перенаправления, которые помогают повысить производительность веб-сайта и SEO.

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

Всегда

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

"trailingSlash": "always"

Запрашиваемая папка	Возвращаемый файл	Состояние ответа	и путь...
/О	Файл /about/index.html	`301`	/about/
/about/	Файл /about/index.html	`200`	/about/
/about/index.html	Файл /about/index.html	`301`	/about/
/Контакт	Файл /contact.html	`301`	/Контакт/
/Контакт/	Файл /contact.html	`200`	/Контакт/
/contact.html	Файл /contact.html	`301`	/Контакт/

Никогда

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

"trailingSlash": "never"

Запрашиваемая папка	Возвращаемый файл	Состояние ответа	и путь...
/О	Файл /about/index.html	`200`	/О
/about/	Файл /about/index.html	`301`	/О
/about/index.html	Файл /about/index.html	`301`	/О
/Контакт	Файл /contact.html	`200`	/Контакт
/Контакт/	Файл /contact.html	`301`	/Контакт
/contact.html	Файл /contact.html	`301`	/Контакт

Авто

Если задано trailingSlashautoзначение, все запросы к папкам перенаправляются по URL-адресу с косой чертой. Все запросы к файлам перенаправляются на URL-адрес косой черты, не связанный с косой чертой.

"trailingSlash": "auto"

Запрашиваемая папка	Возвращаемый файл	Состояние ответа	и путь...
/О	Файл /about/index.html	`301`	/about/
/about/	Файл /about/index.html	`200`	/about/
/about/index.html	Файл /about/index.html	`301`	/about/
/Контакт	Файл /contact.html	`200`	/Контакт
/Контакт/	Файл /contact.html	`301`	/Контакт
/contact.html	Файл /contact.html	`301`	/Контакт

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

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

Запрашиваемая папка	Возвращаемый файл	Состояние ответа	и путь...
/О	Файл /about/index.html	`200`	/О
/about/	Файл /about/index.html	`200`	/about/
/about/index.html	Файл /about/index.html	`200`	/about/index.html
/Контакт	Файл /contact.html	`200`	/Контакт
/Контакт/	Файл /contact.html	`301`	/Контакт
/contact.html	Файл /contact.html	`200`	/contact.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/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"
  }
}

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

Запрашиваемая папка	Возвращаемый результат
/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/twitter	Так как авторизация с помощью Twitter отключена правилом маршрута, `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

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

Маршруты

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

Указание шаблонов маршрутов

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

Шаблон Wild карта

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

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

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

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

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

Платформа

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

.NET

Node.js

Python

Сеть

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

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

Переадресация шлюза

Разрешенные переадресированные узлы

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

Косая черта

Всегда

Никогда

Авто

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

Ограничения

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

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

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