Аутентифицирован, но получаешь 403 — DRF так и задуман

Кандидат на мидл+ путает два разных слоя DRF: аутентификацию и права доступа. Получив 403 вместо 401, начинает чинить токен, хотя токен уже прошёл проверку — проблема в другом классе.

Классы аутентификации (SessionAuthentication, TokenAuthentication, JWT-пакеты) отвечают только на вопрос «кто ты» и кладут объект пользователя в request.user. Если аутентификация не прошла — ответ 401, Unauthorized, запрос не опознан.

Классы permissions работают после: они получают уже опознанного request.user и решают, можно ли ему именно это действие. IsAuthenticated пропустит любого опознанного пользователя, а кастомный IsOwner или IsAdminUser может отказать — и это уже 403, Forbidden: «я знаю, кто ты, но тебе сюда нельзя».

class PolicyViewSet(viewsets.ModelViewSet): authentication_classes = [TokenAuthentication] permission_classes = [IsAuthenticated, IsOwner]

def get_queryset(self): return Policy.objects.filter( client=self.request.user )

Throttling добавляет третий слой — он может вернуть 429 ещё до того, как запрос дойдёт до permissions, если включён троттлинг по IP или по пользователю. Пагинация на этот конвейер не влияет напрямую, но часто спрашивают следом: что произойдёт, если permission_classes пуст — DRF по умолчанию пропустит всех, если явно не задан DEFAULT_PERMISSION_CLASSES в settings. Это частая причина случайно открытого эндпоинта в проде.

401 — ты не опознан, 403 — опознан, но тебе нельзя. Перепутать эти коды в ответе на собесе — минус балл сразу.

Тренажёр: 1900+ вопросов и задач, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки