The Session documentation rightly warns of the dangers of putting a session ID into a query string. Sometimes, however, you have to do it - perhaps your client has mandated support for browsers with cookies disabled, or perhaps (as in my case) you're just dealing with a slightly broken client browser.
This middleware pulls a session ID out of the query string an inserts it into the cookies collection. You'll need to include it in your MIDDLEWARE_CLASSES tuple in settings.py, before the SessionMiddleware.
Please read my full blog post about for the dangers of doing this, and for full instructions and examples.
1 2 3 4 5 6 7 8 9 | from django.conf import settings
class FakeSessionCookieMiddleware(object):
def process_request(self, request):
if not request.COOKIES.has_key(settings.SESSION_COOKIE_NAME) \
and request.GET.has_key(settings.SESSION_COOKIE_NAME):
request.COOKIES[settings.SESSION_COOKIE_NAME] = \
request.GET[settings.SESSION_COOKIE_NAME]
|
More like this
- Template tag - list punctuation for a list of items by shapiromatron 11 months ago
- JSONRequestMiddleware adds a .json() method to your HttpRequests by cdcarter 11 months, 1 week ago
- Serializer factory with Django Rest Framework by julio 1 year, 5 months ago
- Image compression before saving the new model / work with JPG, PNG by Schleidens 1 year, 6 months ago
- Help text hyperlinks by sa2812 1 year, 7 months ago
Comments
I like this snippet, but one question came to my mind: what happens if i call the view with some arbitrary data instead of the session-id in the url (the content of request.GET[settings.SESSION_COOKIE_NAME])? Is there a possibility to inject/break anything here? I'm pretty sure this is not the case, but I would like to here some other opinions on this.
#
Please login first before commenting.