Отображение помогает пользователю ориентироваться
React позволяет показывать разные элементы в зависимости от состояния и условий. Поэтому редактор может видеть кнопку сохранения черновика, а администратор дополнительно видеть управление пользователями. Такая настройка уменьшает путаницу, но относится к представлению интерфейса. Решение браузера о показе кнопки не должно становиться единственным основанием для серверного действия. Даже корректно отображённая страница может устареть после изменения роли пользователя. Серверная часть должна оценивать актуальные условия тогда, когда получает запрос, а не полагаться на то, что когда-то было показано на экране.
Установить личность и разрешить действие не одно и то же
Проверка входа отвечает на вопрос, какой пользователь обращается к системе. Проверка полномочий уточняет, может ли он выполнить определённое действие с выбранной записью. Например, редактор вправе менять собственный черновик, но не чужой. Сам факт успешного входа не разрешает редактирование всех материалов. В серверной части на PHP правило должно учитывать нужные признаки: пользователя, операцию, принадлежность записи и, если предусмотрено, её состояние. Значения, присланные клиентом, нельзя просто принять как доказательство прав. Отсутствие явно предусмотренного разрешения должно приводить к отказу.
Правило удобнее проверить на конкретных сочетаниях
Зададим учебную политику: гость не редактирует материалы, редактор изменяет только свой черновик, администратор может изменять оба учебных черновика. Публикация и удаление пока вообще не разрешены этой моделью. Тогда для двух записей и трёх пользователей можно заранее перечислить ожидаемые решения. Важен случай с чужим черновиком: он показывает, что роли редактора недостаточно без проверки объекта. Такая матрица помогает обсуждать требования и планировать проверки. Она не является готовой системой безопасности: отдельно остаются защита сессии, проверка входных данных, журналирование и другие требования приложения.
Попробуйте на практике
Составьте бумажную матрицу разрешений для вымышленной панели. Настоящий сайт, программный код, учётные записи и сетевые запросы не понадобятся.
- Обозначьте две записи: черновик А принадлежит редактору, черновик Б принадлежит другому человеку. Создайте строки для гостя, этого редактора и администратора.
- Для действия редактирования заполните два столбца по учебной политике. Гостю запретите оба случая, редактору разрешите только А, администратору разрешите А и Б.
- Рядом нарисуйте интерфейс редактора с кнопкой возле А и без кнопки возле Б. Объясните, почему сервер всё равно должен проверять принадлежность выбранного черновика при каждом обращении.
- Добавьте запрос на удаление А и изменение роли редактора до обработки запроса. В первом случае отметьте отсутствие разрешения в модели, во втором необходимость использовать актуальные полномочия, а не прежний вид страницы.
Как проверить результат. Матрица различает пользователя, действие и объект. Для чужого черновика редактор получает отказ, скрытая кнопка не заменяет серверную проверку. Неописанная операция не становится автоматически разрешённой.
Частые вопросы
Достаточно ли один раз проверить роль при открытии панели?
Нет. Полномочия и состояние объекта могут измениться. Проверять разрешение нужно при обработке соответствующего запроса на сервере.
Нужно ли тогда вообще скрывать недоступные кнопки?
Да, это может делать интерфейс понятнее. Просто удобство отображения и серверное решение выполняют разные задачи и должны согласованно работать вместе.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.