Настройка доступа для поставщиков и ролей

Завершено

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

Рассмотрим настройку маршрутизации и роли в Статических веб-приложениях 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"]
    }
  ]
}

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

Затем мы реализуем ограничения доступа в нашем приложении.