Hi Malcolm, Thank you for the tip! I see now that in my particular code example above, the idea of using session id and manually setting it through the request can only work if the session id itself doesn't change after i've set it into the response. From your explaination, there is no guarantee of this happening, so in the code above I've to make sure that the timing of setting it into the response must be the last action before passing it to render_to_response()
Please point out if my logic is mistaken. - i On Jan 21, 9:42 pm, Malcolm Tredinnick <[email protected]> wrote: > On Wed, 2009-01-21 at 04:11 -0800, Iqbal Abdullah wrote: > > Hi guys, > > > I need to support some browsers which doesn't handle cookies, so I > > have followed the snippet here to manually get session ids from the > > request: > >http://www.djangosnippets.org/snippets/460/ > > > and positioned the new middleware before the SessionMiddleware in the > > settings.py file. > > > I did an experiment with a view, which is something like this: > > > 16 def test(request): > > 17 > > 20 ses_key_1 = request.session.session_key > > 24 > > 25 response_dict = {'test_01': "TEST01", > > 27 'test_03': request.session.session_key, > > 28 'sid': request.session.session_key, > > 29 'sid_key': settings.SESSION_COOKIE_NAME , > > 30 } > > 31 request.session['test'] = "test" > > 32 ses_key_2 = request.session.session_key > > 35 > > 36 return render_to_response('test.html', RequestContext(request, > > dict=response_dict)) > > > and found out, that ses_key_1 and ses_key_2 are different session ids > > when the browser (which doesn't handle cookies) accesses it. Can > > anyone explain to me why a new session id was made when there is > > already one for the request? > > One situation where this will happen is when a user logs in. The session > id is changed (although the session contents are retained). This is to > prevent one class of security attacks wherein somebody grabs a session > ID from an anonymous user and it remains valid after that user has > logged in (at which point their whole interaction may have switched to > HTTPS, so snooping the session id is harder for the attacker). Since it > doesn't hurt to change the session id, we do it for everybody when a > login occurs. > > Similarly, if a user ever logs out, their entire session is flushed and > a new session id will be created. > > Other code *may* call the cycle_key() method in the session backends, > but those are the only situations out-of-the-box that will do so. > > The point is, you have to be able to handle the session id changing. It > does not identify the session to Django itself (on the server side). The > session object does that and changing the id within the Python object is > valid. The session id is used by the client side to identify the > particular session object for the next request it makes (and that won't > change outside of a particular user's request). > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
