kurojneko
@kurojneko

Почему django rest framework отвечает 401?

Здравствуйте, столкнулся с проблемой полной магии и волшебства.
Есть паровоз, из джанго с рест фреймворком и эмбера.
Ембер пытается получить данные от сервера, гет запросом, сервер отвечает 401, я пытаюсь вручную получить данные от того же сервера, тем же гет запросом, получаю данные.
Аутентификация токенами, я ее уже отключал, подключил, танцевал с бубном... ничего не понимаю, как будто сервера разные. А самое сложное что даже не знаю куда копать..
На убунте, вся таже связка работала...
  • Вопрос задан
  • 986 просмотров
Пригласить эксперта
Ответы на вопрос 1
@marazmiki
Укротитель питонов
Всё идёт ровно так, как и должно идти, и нет тут ни магии, ни волшебства (ну, разве чуть-чуть: в идеале нигде не должно работать, даже на убунте). И вот почему.

Как Вы наверняка знаете, в обычном, привычном нам вебе, к коему относятся и ручные запросы из браузера, для идентификации клиента придумали такую штуку, как сессия: при первом посещении сервер выдаёт клиенту идентификатор, который клиент затем будет добавлять к каждому запросу (в случае джанги это сессионная кука sessionid). И на своей стороне создаёт хранилище для информации о конкретно этом клиенте.

При каждом запросе сервер проверяет, передан ли от клиента тем или иным способом —а чаще всего это кука — ID сессии. Если передан, то сервер "опознаёт" пользователя. Если нет, то нет :-) Кука добавляется к запросу самим браузером, без явного участия пользователя, поэтому для нас, людишек, всё выглядит как будто само собой.

Теперь про REST. Обычно API пишется чаще всего не для браузеров, а для сторонних серверов, в которых и кук-то зачастую не бывает. И такого понятия, как сессия, просто нет! Каждый запрос приходит как будто он от нового пользователя. Здесь идентифицироваться приходится ручками.

Самый простой, но вместе с тем и самый глупый вариант — вместе с каждым запросом посылать логин и пароль. Другой не самый умный, но почему-то часто встречающийся вариант — захардкоженный секретный параметр: типа если в запросе есть переменная abcdef=123, то запрос считается достоверным.

Логическое продолжение этого способа — та самая аутентификация через токены, которую Вы то включаете, то выключаете. Пользователь шлёт логин и пароль на отдельный URL, в ответ получает токен, который затем должен добавлять вручную к каждому запросу. Что-то напоминает, верно? :-)

В случае с либеральным DRF можно наплевать на рекомендуемый принцип stateless — не сохранять информацию о состоянии клиента — и добавить поддержку сессий: т.е. сделать так, что если в запросе передаётся кука (а любой браузерный запрос, даже через XHR их вроде бы добавляет), то сервер должен определять пользователя.

Включается это довольно просто: нужно использовать
rest_framework.authentication.SessionAuthentication в качестве аутентификатора. Лучше всего сделать глобальную настройку (в документации всё есть), либо указать этот класс для отдельного endpoint.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы