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
- Browser-native date input field by kytta 1 month ago
- Generate and render HTML Table by LLyaudet 1 month, 1 week ago
- My firs Snippets by GutemaG 1 month, 1 week ago
- FileField having auto upload_to path by junaidmgithub 2 months, 2 weeks ago
- LazyPrimaryKeyRelatedField by LLyaudet 2 months, 3 weeks 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.