Hi Davide, Did you take a look at the design decisions as described in the ticket and pull request? We made these decisions in order to push the community toward developing more secure apps and the transition isn't expected to be painless. We had several core developers review the patch and discuss the decisions. It seems like you are asking us to reconsider, but you haven't presented anything we haven't discussed. Would you like me to address anything specific?
Tim On Thursday, September 19, 2013 10:46:44 AM UTC-4, Davide Rizzo wrote: > > #20922 <https://code.djangoproject.com/ticket/20922> introduced the > option to choose a custom session data serializer. The default option is to > use the new JSONSerializer starting from 1.6, since using pickle would lead > to a remote code execution vulnerability when session data is stored in > cookies. > > While this can be considered a sensible security choice, it becomes > inconvenient as the JSON encoder used by JSONSerializer is not the same > used elsewhere in Django, as it only support basic data types: string, > int/floats, booleans, nested dicts and lists, None. > > The inconvenience is breaking compatibility with all third party apps that > rely on storing extended data types (such as those supported by > DjangoJSONEncoder) with the default settings. Properly serializing datetime > (possibly tz-aware) can be hard, and changing the default puts the burden > on third party apps coders. > > They would have the option to either add two complexity layers (properly > serializing/deserializing datetime objects, and not breaking compatibility > with the previous versions of the same app), or to break compatibility with > Django default settings. > > As an example of commonly used data types that can't be stored anymore > with default settings: > > - datetime, timedelta objects (supported by DjangoJSONEncoder) > - decimal objects (supported by DjangoJSONEncoder) > - arbitrary binary strings > - Geometry objects > > I think the option of reverting the default to pickle should be also > considered. > > [[I originally posted this as > #21124<https://code.djangoproject.com/ticket/21124>, > where it was closed as not a bug. What follows is the response I got, for > reference: > > by timo (core developer) > > Thanks for your thoughts. I think most of the points you've raised were > discussed during the implementation of this, either on the ticket > (#20922<https://code.djangoproject.com/ticket/20922>) > or on the linked pull request<https://github.com/django/django/pull/1488> (or > the documentation > itself<https://docs.djangoproject.com/en/dev/topics/http/sessions/#session-serialization>). > > Could you please take a look at the discussion there if you haven't? If > after reading that you still have disagreements, please raise the issue on > django-developers rather than this ticket tracker. Thanks! > > Suggestions for documentations edits or additions would also be welcome. > > p.s. To address one of your points, one of the decisions was indeed to put > the burden on third party app coders to serialize session data as simple > data types like strings which would be compatible with JSON. We made this > change to contrib.messages for example. > ]] > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
