a67ab33e5d
SPA аутентифицируется сессионной кукой и не прикладывает X-CSRFToken, а
SessionAuthentication из DRF требует его на любом небезопасном методе:
DELETE /api/core/videos/<id>/ -> 403
{"detail": "CSRF Failed: CSRF token missing."}
Проверено на контуре, тремя запросами по несуществующему id (403 = отказ
авторизации, 404 = авторизация прошла):
Bearer-токен -> 404 CSRF не при чём
сессия + X-CSRFToken -> 404 проходит
сессия без X-CSRFToken -> 403 ровно наша ошибка
без авторизации -> 401
То есть бэкенд исправен, ломается ровно сочетание "кука без заголовка".
С Bearer до SessionAuthentication дело не доходит: simple_jwt стоит в
DEFAULT_AUTHENTICATION_CLASSES раньше.
Ставим подкласс с пустым enforce_csrf на то же пятое место. Цена — с
cookie-запросов снимается защита от CSRF. Основной вектор закрыт самими
куками (sessionid и csrftoken выставляются с SameSite=Lax, браузер не
пошлёт их при кросс-сайтовом DELETE); остаётся щель в соседях по домену,
поскольку SameSite смотрит на site, а не на origin.
Импорт rest_framework в модуле настроек безопасен не всегда — обычно так
ловят AppRegistryNotReady. Здесь проверено запуском django.setup() внутри
работающего пода backend: setup проходит, строка пути к классу резолвится.
|
||
|---|---|---|
| .. | ||
| aero | ||
| base | ||
| brusnika-prod | ||
| brusnika-stage | ||
| d8-ugmk-prod | ||
| dsinv | ||
| yc-ecp | ||
| yc-k8s-test | ||
| .env.example | ||
| CONFIGURATION.md | ||
| ENDPOINTS.md | ||
| FRONTEND_REQUESTS.md | ||
| openapi.yaml | ||