Sessions being written twice?
Iqbal Abdullah
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?
Malcolm Tredinnick
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
shi shaozhong
Iqbal Abdullah
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 <malc...@pointy-stick.com>
wrote:
Malcolm Tredinnick
> 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 must admit that I don't really understand what you're trying to do
here. However, I would strongly suggest simply following the same logic
as the existing session middleware, which seems to involve setting
things at the last minute.
Personally, though, if I had to work on a system that didn't allow
cookies, I'd try to avoid using Django's session framework. You don't
need sessions very much in many situations (the usual amount is to
record that somebody is logged in and an encrypted form variable of URL
parameter could do that), so you might be trying to solve a small
problem with a large and awkward hammer.
In any case, good luck.
Regards,
Malcolm