Доступ к информации о сеансе / запросе за пределами представлений в Джанго

Question

Мне нужно хранить специальные куки-файлы, которые приходят из не-django-приложений.Я могу сделать это в представлениях

request.session[special_cookies'] = special_cookies

Но в файлах py, не относящихся к представлениям, мне нужно получить доступ к этим специальным файлам cookie.сделать это

>>> from django.contrib.sessions.backends.db import SessionStore
>>> import datetime
>>> s = SessionStore(session_key='2b1189a188b44ad18c35e113ac6ceead')
>>> s['last_login'] = datetime.datetime(2005, 8, 20, 13, 35, 10)
>>> s['last_login']
datetime.datetime(2005, 8, 20, 13, 35, 0)
>>> s.save()

Если я не предоставлю ключ сессии, Django сгенерирует его для меня.Я обеспокоен эффектом получения многих новых сеансовых ключей.(Я не думаю, что это хорошо, когда у вас несколько пользователей, верно ...?)

Я хочу, чтобы пользователь привязал эти специальные куки-файлы к сеансу пользователя. Однако , я не хочу сохранять это в профиле пользователя, потому что по соображениям безопасности.Этот файл cookie создается при входе в систему (наше приложение отправляет эти специальные файлы cookie).Мы хотим отправлять этот cookie туда и обратно на протяжении всего сеанса просмотра.

Как мне решить эту проблему?

Большое спасибо!

---

#views.py
request.session['special_cookies'] = library.get_special(user, pwd)

#library.py
def get_special_cookies(user, pwd):
   res = get_special_cookies("http://foobar.com/api/get_special_cookies", user, pwd)

#foobar.py  (also non-views)
def do_this(user, special_cookies)

Я почти уверен, что это хорошо ....

#views_2.py
def dummy_views(request):
    foobar.do_this(request.user, request.session['special_cookies'])

Но есть случаи, когда я не хочу получать свои специальные куки-файлы через представления / вызовы get_sepcial_cookies.Я хочу, чтобы это продолжалось повсюду.Или я переосмысливаю ..?

Answer 1

Чтобы объяснить, почему вы находитесь на опасном пути, мы должны вспомнить, почему сеансы на стороне сервера были изобретены в первую очередь:

HTTP - это протокол без сохранения состояния . Протокол без сохранения состояния не требует от сервера сохранять информацию или статус о каждом пользователе в течение нескольких запросов. Например, когда веб-серверу требуется настроить содержимое веб-страницы для пользователя, веб-приложению может потребоваться отслеживать продвижение пользователя от страницы к странице. Распространенным решением является использование файлов cookie HTTP. Другие методы включают сеансы на стороне сервера, скрытые переменные (когда текущая страница содержит форму) и перезапись URL с использованием параметров в кодировке URI.

Джанго - очень зрелая основа; если в Django трудно достичь какой-то цели, возможно, вы неправильно подходите к проблеме. Даже если вы можете хранить информацию о сеансе на стороне сервера непосредственно в бэкэнде сеанса, для меня это кажется плохим дизайном, потому что данные сеанса не имеют отношения к внешним запросам.

ИМХО, если вам нужно обмениваться данными аутентификации / авторизации между приложениями, вам следует рассмотреть что-то вроде OAuth , в противном случае вы получите что-то небезопасное, хрупкое, уродливое и сложное для поддержки.

(извините, если я звучу снисходительно, английский не является моей родной идиомой).

[обновление]

Привет, Пауло. Большое спасибо. Я считаю, что моя команда не хочет вводить OAuth или какой-либо дополнительный уровень механизма аутентификации. Но вы против вставки этих специальных файлов cookie в HttpResponse.COOKIES?

Несколько замечаний, если вы действительно хотите пойти по этому пути:

• вы будете ограничены ограничением "тот же домен" (другое приложение должно находиться в том же TLD)
• вы должны использовать какую-то подпись, чтобы избежать вмешательства в файлы cookie

Это лучшее решение, чем request.session?

Есть некоторые механизмы для решения этой проблемы на более высоком уровне. Например:

• если вы хотите, чтобы переменная присутствовала в каждом контексте шаблона на основе значения некоторого файла cookie, вы можете написать собственный процессор контекста .
• если вы хотите перенаправить представления в зависимости от наличия файла cookie, вы должны написать пользовательское middleware .

Я не могу предоставить более конкретное решение без дополнительной информации о ваших целях, но с помощью этих хуков вы можете избежать повторения кода для проверки на наличие внешнего куки в каждом представлении - однако учтите, что все, что касается куки, связано с запросом / контекст контекста и не имеет смысла вне его.