diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt
index 1e71e1d..72d4df0 100644
a
|
b
|
Default session serialization switched to JSON
|
745 | 745 | Historically, :mod:`django.contrib.sessions` used :mod:`pickle` to serialize |
746 | 746 | session data before storing it in the backend. If you're using the :ref:`signed |
747 | 747 | cookie session backend<cookie-session-backend>` and :setting:`SECRET_KEY` is |
748 | | known by an attacker, the attacker could insert a string into his session |
| 748 | known by an attacker (there isn't an inherent vulnerability in Django that |
| 749 | would cause it to leak), the attacker could insert a string into his session |
749 | 750 | which, when unpickled, executes arbitrary code on the server. The technique for |
750 | 751 | doing so is simple and easily available on the internet. Although the cookie |
751 | 752 | session storage signs the cookie-stored data to prevent tampering, a |
… |
… |
For backwards compatibility, this setting defaulted to using :mod:`pickle`
|
759 | 760 | in Django 1.5.3, but we've changed the default to JSON in 1.6. If you upgrade |
760 | 761 | and switch from pickle to JSON, sessions created before the upgrade will be |
761 | 762 | lost. While JSON serialization does not support all Python objects like |
762 | | :mod:`pickle` does, we highly recommend using JSON-serialized sessions. See the |
| 763 | :mod:`pickle` does, we highly recommend using JSON-serialized sessions. Also, |
| 764 | as JSON requires string keys, you will likely run into problems if you are |
| 765 | using non-string keys in ``request.session``. See the |
763 | 766 | :ref:`session_serialization` documentation for more details. |
764 | 767 | |
765 | 768 | Miscellaneous |
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index 47be4c6..8bef7f2 100644
a
|
b
|
Session serialization
|
314 | 314 | Before version 1.6, Django defaulted to using :mod:`pickle` to serialize |
315 | 315 | session data before storing it in the backend. If you're using the :ref:`signed |
316 | 316 | cookie session backend<cookie-session-backend>` and :setting:`SECRET_KEY` is |
317 | | known by an attacker, the attacker could insert a string into his session |
| 317 | known by an attacker (there isn't an inherent vulnerability in Django that |
| 318 | would cause it to leak), the attacker could insert a string into his session |
318 | 319 | which, when unpickled, executes arbitrary code on the server. The technique for |
319 | 320 | doing so is simple and easily available on the internet. Although the cookie |
320 | 321 | session storage signs the cookie-stored data to prevent tampering, a |
… |
… |
Bundled Serializers
|
338 | 339 | .. class:: serializers.JSONSerializer |
339 | 340 | |
340 | 341 | A wrapper around the JSON serializer from :mod:`django.core.signing`. Can |
341 | | only serialize basic data types. See the :ref:`custom-serializers` section |
342 | | for more details. |
| 342 | only serialize basic data types. |
| 343 | |
| 344 | In addition, as JSON supports only string keys, note that using non-string |
| 345 | keys in ``request.session`` won't work as expected:: |
| 346 | |
| 347 | >>> # initial assignment |
| 348 | >>> request.session[0] = 'bar' |
| 349 | >>> # subsequent requests following serialization & deserialization |
| 350 | >>> # of session data |
| 351 | >>> request.session[0] # KeyError |
| 352 | >>> request.session['0'] |
| 353 | 'bar' |
| 354 | |
| 355 | See the :ref:`custom-serializers` section for more details on limitations |
| 356 | of JSON serialization. |
343 | 357 | |
344 | 358 | .. class:: serializers.PickleSerializer |
345 | 359 | |