kurojneko
@kurojneko

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

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

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

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

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

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

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

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

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

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

Войти через центр авторизации
Похожие вопросы