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