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

← К оглавлению урока | ← К заданиям

⚡ Краткие ответы

  • В1: 1-c, 2-a, 3-b, 4-d
  • В2: a
  • В3: c (TokenAuthentication)
  • В4: b (403 Forbidden)
  • В5: a
  • В6: a, c, d
  • В7: a, c, d
  • В8: a (AnonymousUser)
  • В9: b (POST)
  • В10: b (BasicAuthentication)
  • В11: 1-c, 2-a, 3-b
  • В12: c
  • В13: b
  • В14: c (Bearer)

Блок 1: Аутентификация и авторизация

Вопрос 1 — Сопоставление механизмов

Ответ: 1-c, 2-a, 3-b, 4-d
  • 1 (SessionAuthentication) → c: использует сессии и куки
  • 2 (BasicAuthentication) → a: базовая HTTP-аутентификация
  • 3 (TokenAuthentication) → b: токены в каждом запросе
  • 4 (RemoteUserAuthentication) → d: HTTP-заголовок REMOTE_USER

Вопрос 2 — Верное утверждение об аутентификации

Ответ: а

Аутентификация проверяет учётные данные для установления личности пользователя. Вариант «б» описывает авторизацию — определение прав доступа.

Вопрос 3 — Механизм для RESTful API

Ответ: c (TokenAuthentication)

TokenAuthentication хорошо подходит для RESTful API и мобильных приложений — не требует куки, работает через заголовок. SessionAuthentication привязан к браузеру, BasicAuthentication небезопасен без HTTPS, RemoteUserAuthentication — для корпоративных SSO.

Вопрос 4 — Неудачная авторизация

Ответ: b (HTTP 403 Forbidden)

При неудачной авторизации DRF выбрасывает исключение PermissionDenied, которое транслируется в HTTP 403 Forbidden. Запрос не продолжается и не перезапускается.

Вопрос 5 — Авторизация после аутентификации

Ответ: a

После успешной аутентификации авторизация проверяет, имеет ли пользователь права доступа к конкретным ресурсам или действиям. Вопрос «кто ты» — это уже решён на этапе аутентификации.

Блок 2: BasicAuthentication и TokenAuthentication

Вопрос 6 — Верные утверждения о BasicAuthentication

Ответ: a, c, d
  • a) — верно: учётные данные в каждом запросе в заголовке Authorization
  • b) — неверно: небезопасен без HTTPS (Base64 — не шифрование!)
  • c) — верно: не требует сессий или куки
  • d) — верно: кодируется в Base64

Вопрос 7 — Настройка TokenAuthentication

Ответ: a, c, d
  • a) — верно: нужен rest_framework.authtoken в INSTALLED_APPS
  • b) — неверно: TokenAuthentication не использует сессии и куки
  • c) — верно: нужны миграции для создания таблицы authtoken_token
  • d) — верно: нужно добавить в DEFAULT_AUTHENTICATION_CLASSES

Вопрос 8 — Отсутствующий токен

Ответ: a (AnonymousUser)

Если токен отсутствует или недействителен, аутентификация «проваливается молча»: request.user = AnonymousUser. Отказ в доступе (403) происходит только на этапе проверки разрешений, если используется IsAuthenticated.

Вопрос 9 — HTTP-метод для токена

Ответ: b (POST)

Для получения токена используется POST-запрос с телом username + password. GET не несёт тела запроса, поэтому не подходит.

Вопрос 10 — Небезопасный без HTTPS

Ответ: b (BasicAuthentication)

BasicAuthentication кодирует логин:пароль в Base64 и передаёт их в каждом запросе. Base64 — это кодирование, не шифрование. Без HTTPS данные перехватываются в открытом виде.

Блок 3: JWT

Вопрос 11 — Части JWT

Ответ: 1-c, 2-a, 3-b
  • 1 (Header) → c: метаданные (тип, алгоритм)
  • 2 (Payload) → a: утверждения о пользователе
  • 3 (Signature) → b: подпись для проверки целостности

Вопрос 12 — TokenObtainPairView

Ответ: c

TokenObtainPairView возвращает пару токенов: access (короткий срок, для запросов) и refresh (долгий срок, для получения нового access). TokenRefreshView обновляет access по refresh.

Вопрос 13 — Что происходит при проверке JWT

Ответ: b

Сервер декодирует токен и проверяет его подпись (HMAC/RSA) и срок действия (exp claim). Сессия не создаётся — JWT stateless. Токен не обновляется автоматически.

Вопрос 14 — Формат заголовка для JWT

Ответ: c — Bearer <token>

Стандарт OAuth 2.0 / RFC 6750 определяет схему Bearer для JWT. Token — это формат DRF TokenAuthentication. JWT и Auth — не стандартные схемы.