✅ Решения — Урок 42

← К оглавлению урока

⚡ Правильные ответы

  1. б — request.user
  2. в — выполняет дополнительный код перед сохранением
  3. б — read_only_fields
  4. б — has_object_permission
  5. в — при GET к списку (list)
  6. в — True
  7. б — view, add, change, delete
  8. а — упрощают администрирование
  9. в — DjangoModelPermissions
  10. г — все вышеперечисленные

Блок 1: Получение пользователя из request

Вопрос 1 — Ответ: б) request.user

В DRF объект request расширяет стандартный Django-запрос. Атрибут request.user содержит объект аутентифицированного пользователя (или AnonymousUser для неаутентифицированных запросов). Именно этот атрибут используется во всех операциях, связанных с текущим пользователем.

  • request.auth — содержит объект аутентификации (токен, сессию), но не пользователя
  • request.data — тело запроса (POST/PUT данные)
  • request.user.is_authenticated — булево значение, проверяет статус входа

Вопрос 2 — Ответ: в) Выполняет дополнительный код перед сохранением

Метод perform_create(self, serializer) вызывается в момент создания объекта через POST-запрос. Он позволяет добавить дополнительные данные или выполнить логику перед финальным сохранением. Стандартная реализация просто вызывает serializer.save(). Переопределяя её, мы передаём дополнительные поля, например owner=self.request.user.

Вопрос 3 — Ответ: б) read_only_fields

Поле в read_only_fields автоматически исключается из обработки входящих данных (десериализации). Клиент не обязан его передавать. При этом поле остаётся в ответе (сериализации). Это идеальный подход для полей, устанавливаемых автоматически на сервере.

Блок 2: Разрешения на уровне объектов

Вопрос 4 — Ответ: б) has_object_permission

Метод has_object_permission(self, request, view, obj) получает конкретный объект из базы данных и проверяет, имеет ли пользователь права на действие с ним. Он вызывается из get_object() в Generic Views и ViewSets, когда происходит retrieve, update или destroy.

  • has_permission — проверяет доступ к представлению в целом (до загрузки объекта)
  • check_permission и validate_permission — не существуют в DRF

Вопрос 5 — Ответ: в) При GET к списку объектов

Метод has_object_permission вызывается только тогда, когда представление вызывает self.get_object() — то есть при работе с конкретным объектом (detail). При запросе к списку (list) объект ещё не определён, поэтому метод не вызывается. Для защиты list-эндпоинтов используйте has_permission или фильтруйте get_queryset().

Вопрос 6 — Ответ: в) True

Оба метода BasePermission должны возвращать булево значение: True — доступ разрешён, False — доступ запрещён. При False DRF генерирует ответ 403 Forbidden.

Блок 3: Разрешения моделей

Вопрос 7 — Ответ: б) view, add, change, delete

Django автоматически создаёт четыре разрешения при выполнении миграций для каждой модели:

  • view_<model> — просмотр
  • add_<model> — добавление
  • change_<model> — изменение
  • delete_<model> — удаление

Они хранятся в таблице auth_permission и управляются через Django Admin.

Вопрос 8 — Ответ: а) Упрощают администрирование и масштабируемость

Группы позволяют назначать права сразу набору пользователей: достаточно добавить пользователя в группу «Редакторы» — и он автоматически получит все права группы. Это на порядок удобнее индивидуального назначения в крупных приложениях.

Вопрос 9 — Ответ: в) DjangoModelPermissions

Класс DjangoModelPermissions из rest_framework.permissions автоматически сопоставляет HTTP-методы с Django-разрешениями: POST → add, PUT/PATCH → change, DELETE → delete. Таким образом, разрешения, настроенные в Django Admin, управляют доступом к DRF API без дополнительного кода.

Вопрос 10 — Ответ: г) Все вышеперечисленные

Все три класса являются классами разрешений DRF и контролируют доступ к ресурсам API:

  • DjangoModelPermissions — контроль через Django Admin-разрешения
  • IsAuthenticated — только для аутентифицированных пользователей
  • AllowAny — разрешает доступ всем, включая анонимных (используется для публичных эндпоинтов)