Access session / request information outside of views in Django

Question

I need to store a special cookies that is coming from some non-django applications. I can do this in views

request.session[special_cookies'] = special_cookies

But in the non-views py files, I need to access this special cookies.

According to docs, I can do this

>>> 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()

If I don't supply the session key, Django will generate one for me. I am concerned about the effect of getting many new session keys. (I don't think this is good when you have multiple users, right...?)

I want a user to have this special cookies binded to a user's session. However, I do not want to save this in a user profile, because for security reason. This cookie is generated when we login (our application will send in this special cookies). We want to send this cookie back and forth throughout the browsing session.

How should I go about solving this?

Thank you very much!

---

#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)

I am pretty sure this is fine....

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

But there are instances where I don't want to get my special cookies through views / calling get_sepcial_cookies. I want it to last throughout. Or am I overthinking..?

Answer 1

In order to explain why you are in a dangerous path, we have to remember why server side sessions where invented in the first place:

HTTP is a stateless protocol. A stateless protocol does not require the server to retain information or status about each user for the duration of multiple requests. For example, when a web server is required to customize the content of a web page for a user, the web application may have to track the user's progress from page to page. A common solution is the use of HTTP cookies. Other methods include server side sessions, hidden variables (when the current page contains a form), and URL-rewriting using URI-encoded parameters.

Django is a very mature framework; if some goal seems hard to accomplish in Django, probably you are taking the wrong approach to the problem. Even if you can store server side session information directly at the session backend, it seems like bad design for me, because session data is not relevant outside requests.

IMHO, if you need to share authentication/authorization data among applications, you should really consider something like OAuth, otherwise you will end up with something insecure, fragile, ugly and hard to support.

(sorry if I sound condescending, English is not my native idiom).

[update]

Hi Paulo. Thank you very much. I believe my team doesn't want to introduce OAuth or any sort of extra layer of authetication mechaicism. But are you against inserting this special cookies into HttpResponse.COOKIES?

A few remarks if you you really want to go this way:

• you will be constrained by the "same domain" restriction (the other application should reside in the same TLD)
• you should use some sort of signing to avoid tampering with the cookies

Is that a better solution than request.session?

There are some mechanisms to deal with this kind of problem at a higher level. For example:

• if you want to make a variable present at every template context based on the value of some cookie, you can write a custom context processor.
• if you want to reroute views depending on the presence of a cookie, you should write a custom middleware.

I can't provide a more specific solution without further details about your goals, but using these hooks you can avoid repeating code to test for the external cookie in every view - note however that everything concerning cookies is tied to the request/response context and makes no sense outside it.