Настройка доступа для поставщиков и ролей
При использовании проверки подлинности пользователя веб-приложению со списком покупок требуется способ ограничить доступ к некоторым страницам для пользователей, которые не вошли в систему, и разрешить вход только через определенных поставщиков.
Рассмотрим настройку маршрутизации и роли в Статических веб-приложениях Azure для точной настройки доступа пользователей к нашему веб-приложению.
Файл конфигурации для Статических веб-приложений Azure
Конфигурация для Статические веб-приложения Azure определена в staticwebapp.config.json
файле, который управляет следующими параметрами:
- Маршрутизация
- Аутентификация
- Авторизация
- Правила резервных маршрутов
- Переопределения ответов HTTP
- Глобальные определения заголовков HTTP
- Пользовательские типы MIME
Рекомендуемое расположение для staticwebapp.config.json
находится в наборе папок в качестве параметра app_location
, выбранного во время развертывания. Но вы можете поместить этот файл в любой папке исходного кода приложения.
В нашем случае мы рассмотрим конфигурацию маршрутизации, чтобы достичь желаемого.
Ограничение поставщиков проверки подлинности
В предыдущем разделе мы увидели, что по умолчанию включены все поставщики проверки подлинности. Это можно изменить, добавив правила маршрутизации в конфигурацию.
Например, чтобы отключить вход через поставщика GitHub, можно добавить в файл staticwebapp.config.json
приведенное ниже правило маршрутизации.
{
"routes": [
{
"route": "/.auth/login/github",
"statusCode": 404
}
]
}
Мы заставляем маршрут /.auth/login/github
, используемый для проверки подлинности поставщика GitHub, возвращать ошибку 404
(Не найдено), чтобы пользователи не могли получить к нему доступ. Вы можете добавить любое количество правил маршрутов, чтобы отключить всех поставщиков, которых вы не хотите использовать.
Защита маршрутов с помощью ролей
Маршруты по умолчанию доступны всем без ограничений. Маршруты можно защитить, добавив одно или несколько имен ролей в массив правила allowedRoles
. По умолчанию каждый пользователь принадлежит к встроенной роли anonymous
, а все вошедшие в систему пользователи являются членами роли authenticated
.
Это означает, что для предоставления доступа к маршруту только пользователям, прошедшим проверку подлинности, можно добавить встроенную роль authenticated
в массив allowedRoles
.
{
"routes": [
{
"route": "/profile",
"allowedRoles": ["authenticated"]
}
]
}
В такой конфигурации, если пользователь, не прошедший проверку подлинности, попытается получить доступ к маршруту /profile
, будет возвращена ошибка 401
(недостаточно прав доступа).
Вы также можете ограничить определенные методы HTTP для данного маршрута следующим образом.
{
"routes": [
{
"route": "/profile",
"methods": ["PUT", "POST", "DELETE"],
"allowedRoles": ["authenticated"]
}
]
}
В этом примере все пользователи могут получить доступ к методу GET
маршрута /profile
, но только пользователи, прошедшие проверку подлинности, могут использовать PUT
, POST
или DELETE
.
Использование подстановочного знака
Подстановочный знак можно использовать в конце маршрута, чтобы сопоставить все маршруты, которые следуют за базовым шаблоном. Например, чтобы предоставить доступ ко всем URL-адресам, начинающимся с /api
, только для пользователей, прошедших проверку подлинности, можно написать следующий фрагмент кода:
{
"routes": [
{
"route": "/api/*",
"allowedRoles": ["authenticated"]
}
]
}
Следующие шаги
Затем мы реализуем ограничения доступа в нашем приложении.