Ответ
Ролевая модель (RBAC — Role-Based Access Control) — это механизм управления доступом, в котором права на выполнение операций в системе назначаются не конкретным пользователям, а их ролям (например, «Администратор», «Пользователь», «Гость»). Тестирование RBAC проверяет корректность работы этой модели.
Что проверяется:
- Позитивные сценарии: Пользователь может выполнять действия, разрешенные его роли.
- Негативные сценарии: Пользователь не может выполнять действия, запрещенные его роли (проверка на отсутствие несанкционированного доступа).
- Эскалация привилегий: Невозможность получить права более высокой роли обходными путями (например, подмена параметров в URL или API-запросе).
Пример теста на Python с использованием pytest:
def test_admin_can_delete_user(admin_client):
response = admin_client.delete('/api/users/123')
assert response.status_code == 200 # Админ имеет право
def test_user_cannot_delete_user(user_client):
response = user_client.delete('/api/users/123')
assert response.status_code == 403 # Обычный пользователь получает "Запрещено"Ключевые аспекты для тестировщика:
- Понимание матрицы прав для каждой роли.
- Проверка доступа к UI-элементам (кнопки, меню) и API-эндпоинтам.
- Тестирование сценариев, когда у пользователя несколько ролей одновременно.
Ответ 18+ 🔞
Да ты посмотри, что вытворяют эти ваши ролевые модели, RBAC называется! Ну внатуре, как в детском саду: вот тебе роль «Администратор» — можешь всё, хоть сервер выключи, а вот тебе «Гость» — сиди, смотри и не пизди. А между ними ещё куча народу: «Пользователь», «Модератор», «Полупидор с доступом только к отчётам». И вся эта система, блядь, должна работать как часы, а иначе — пиздец, любой хитрожопый пользователь может впендюрить туда, куда не следует.
Так вот, слушай, как это дерьмо проверять надо. Главное — не просто убедиться, что админ может всё (это и дурак проверит), а что все остальные нихуя не могут там, где не положено. Это и есть суть, ёпта!
Что гоняем, как проклятые:
- Позитивчик: Роль может делать то, что ей прописано. Админ удаляет пользователя — окей, молодца, получи конфетку.
- Негативчик, он же самый важный: А вот если обычный юзер пытается удалить другого юзера — ему должна прилететь люлей в виде ошибки 403 (Forbidden, блядь, «запрещено»). Если не прилетает — всё, система поехала, можно собирать чемоданы.
- Эскалация привилегий — наш главный страх: Это когда какой-нибудь умник думает: «А вдруг если я в URL-е поменяю
user_id=123наuser_id=1(это админ), то система обосрётся и даст мне его права?». Или в POST-запросе попробует передать"role": "admin". Вот на это надо охотиться, как на дичь! Если система на такое ведётся — это не RBAC, а пизда с ушами.
Смотри, как это в коде выглядит, простой пример:
def test_admin_can_delete_user(admin_client):
response = admin_client.delete('/api/users/123')
assert response.status_code == 200 # Админ имеет право, всё чики-пуки
def test_user_cannot_delete_user(user_client):
response = user_client.delete('/api/users/123')
assert response.status_code == 403 # Обычному юзеру — дверь в рыло, доступ запрещён!И ещё, блядь, ключевые моменты для тестировщика, чтобы не облажаться:
- Матрица прав — это твоя библия. Знать надо наизусть, кто что может. Без этого ты как слепой котёнок.
- Гонять надо ВСЁ: И кнопки в интерфейсе (чтоб у гостя кнопка «Удалить» вообще не отображалась), и API-шные endpoints, куда можно тыркнуться напрямую. Часто бывает, что кнопку спрятали, а запрос пропустили — вот тебе и дыра!
- Смежные роли: А что если у человека сразу две роли? «Пользователь» и «Модератор»? Не конфликтуют ли они? Не откроется ли ему какая-нибудь ебаная дыра, которую никто не предвидел? Это тоже проверять!
Короче, задача — не дать системе превратиться в проходной двор, где каждый встречный-поперечный может начудить. Волнение, блядь, на каждом шагу, но если всё проверить — можно спать спокойно. Ну, почти.