Права доступа в DRF на уровне объектов
Вопрос
Как вы реализуете права доступа в DRF-проекте, где у пользователей роли, а объекты принадлежат организациям?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Аутентификация отдельно от авторизации: кто ты и что тебе можно
Видимость через `get_queryset`: только объекты своей организации
Роли: permission-классы на действия (`has_permission`)
Объектный уровень: `has_object_permission` в `get_object`
Безопасные значения по умолчанию, 404 вместо 403 для чужих объектов
Тесты матрицы ролей и действий
Что могут спросить следом
- Почему иногда лучше вернуть 404, а не 403?
- Где проверять права в фоновых задачах?
Разбор
Образцовый ответ: «Разделяю два вопроса. Видимость решает get_queryset: пользователь видит только объекты своей организации, это фильтр в одном месте, и он работает и для списков, и для детальных запросов. Если объект чужой, get_object вернёт 404, и мы не раскрываем, что такой id существует. Права на действия, кто может создавать, редактировать, удалять, описываю permission-классами: has_permission проверяет роль для всего запроса, например менеджер может создавать заказы, а бухгалтер только читать. Тонкие правила на конкретный объект, например редактировать можно только черновик или только свой, кладу в has_object_permission, он сработает внутри get_object. В настройках по умолчанию IsAuthenticated, всё публичное открываю явно. Для сложных систем роли и разрешения храню в данных, а не в коде. И обязательно тесты на матрицу роль на действие, включая попытки доступа к чужой организации. В фоновых задачах права проверяю там же, где принимается решение, не полагаясь, что вьюха уже всё проверила».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.