On Wed, May 16, 2012 at 4:38 PM, Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote: > 2012/5/16 Tom Evans <tevans...@googlemail.com>: >> So, is the session key being available part of the API, or is relying >> on the session key existing incorrect? > > Hi Tom, > > Accessing the session key before saving the session is incorrect. > > Previously, it used to return something, but that something could be > random data instead of the actual session key. Now it returns None, > making the error more obvious. > > For more information, see https://code.djangoproject.com/ticket/11555 > > Best regards, >
Hi Aymeric Looking at the 1.3 code for sessions, I can understand why this changed. If the generated key collides with a pre-existing session, new session keys are generated until it does not, and the session key is changed from the initial one. However, I do not understand the logic behind the change that fixes this issue. When we create a session object for a user who does not have a session id, it seems logical to me that at that point we are creating the session - the user does not have a session, all users have sessions, this user must be created a session. Instead, the session is not created until after the request has been finished, I presume in order to only create a session when something is written to it, and to avoid saving the session twice in the initial request. Even with this optimization, if I access the session_key of a session object, it should be apparent that I want the session id of the current session. If that means that the session must be saved in order to determine what that session id is, then that is what should happen. I believe in POLA, and to me it is astonishing that a valid session does not have an session id when queried, even temporarily. I find it strange this change was neither documented nor mentioned in the release notes. In the ticket, you said: "From the user's point of view, returning None instead of a wrong session key is probably better, although it might break code that relies on getting a string." (actually you return None instead of a correct session id, except when that session id collides with an existing one) and "That is a rather big change, so I'd like to hear from someone else before working on it." You had clearly grasped that this was a change that could easily break peoples code. I'd like to know why that information was not relayed into the release notes, or anything about the volatility of session keys added to the docs. Even though I don't like the API, if it had been in the relnotes, I wouldn't have spent half a day hunting through the relnotes, docs and finally diffs to determine what had changed and produce a test case, I would simply have been able to update the places that refer to session id to ensure that they existed before use. Cheers Tom PS: I sometimes am accused of coming of as personally confrontational or critical. This is _absolutely_ not what I'm trying to say here! Something like this should have been included in the relnotes, so perhaps a better process can be used in future to ensure that changes like this are properly documented. To Aymeric's credit, he had realised when he changed this that it could/would affect people, his knowledge should have been included in the relnotes! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
