#python #django #django-rest-framework #python-requests
#python #django #django-rest-framework #python-запросы
Вопрос:
У меня есть проект Django, который в конечном итоге будет состоять из трех приложений. Два из которых будут «обычными» приложениями Django, третье — djangorestframework приложение. Я также планирую в какой-то момент создать настольный клиент для проекта.
Я хочу, чтобы приложение rest было единственным объектом, взаимодействующим с базой данных. Следовательно, я использую requests для связи с конечными точками rest из представлений «обычных» приложений Django, и я сделаю то же самое для настольного клиента.
Я хочу, чтобы все приложения были доступны только для аутентифицированных пользователей, поэтому я использую серверную часть аутентификации Django.
Мой вопрос заключается в том, как передать аутентифицированного пользователя / сеанс из приложений pure Django конечным точкам rest при использовании requests в представлениях.
Мне удалось пройти аутентификацию в rest API, используя request ‘s HTTPBasicAuth , но для этого мне необходимо иметь под рукой пароль пользователя в виде обычного текста. Конечно, я мог бы создать технического пользователя для выполнения этих запросов. Но это также означало бы, что каждый запрос должен был бы сначала проходить аутентификацию, а это не кажется лучшим подходом.
Я попытался извлечь файл cookie сеанса из request объекта, который предоставляется представлениям, и передать его через requests.get , но не смог правильно поместить его в requests.get вызов.
На данный момент использование запросов и установленных сеансов выглядит как мой лучший выбор, тем более, что именно так будет поступать и настольный клиент. Итак, в настоящее время я ищу правильный способ предоставить requests.get файл cookie сеанса, но я, безусловно, открыт для лучших решений.
Ответ №1:
Вы должны использовать токены.
В принципе, любой вид аутентификации из вашего проекта django должен управляться с помощью безопасных токенов.
И да, проверка подлинности должна происходить каждый раз, когда вы отправляете запрос. Чтобы ускорить работу, вы можете хранить токены в памяти. (Вы можете использовать redis или, возможно, даже загрузить свою базу данных в память или … ) но это правильный и распространенный способ для этого. Даже django выполняет эту проверку каждый раз, используя свои встроенные функции.
В документах DRF рекомендовано несколько пакетов для управления этими токенами:
Я использовал knox для многих проектов, и это довольно хорошо.
В принципе, для аутентификации ваших пользователей во всех ваших проектах или микросервисах вам нужно взять токен у пользователя, установить его в качестве заголовка или … для вашего запроса к основной базе данных или проекту аутентификации.
Большинство приложений используют токен в заголовках, которые вы можете просто добавить ко всем своим requests вызовам:
Комментарии:
1. Спасибо за ваш ответ. Я читал о token auth, но не чувствовал себя комфортно, используя его, поскольку я еще не изучил это достаточно, чтобы полностью понять, как это работает. Я обязательно попробую. Да, проверки подлинности должны выполняться для каждого запроса. Я имел в виду, что при использовании BasicAuth пользователь будет (повторно) аутентифицироваться для каждого запроса, тогда как при использовании сеансов (или токенов, если уж на то пошло) это сводилось бы к проверке того, является ли предоставленный сеанс (или токен) действительным.
2. Ну, может быть, это неудобно, но это то, что все используют. Вы можете проверить несколько API для крупных компаний и других проектов с открытым исходным кодом, чтобы получить лучшее представление, но это лучший способ, если не единственно правильный.