Search code examples
djangodjango-sessions

How much can request.session store?

I'm new to learning about Django sessions (and Django in general). It seems to me that request.session functions like a dictionary, but I'm not sure how much data I can save on it. Most of the examples I have looked at so far have been using request.session to store relatively small data such as a short string or integer. So is there a limit to the amount of data I can save on a request.session or is it more related to what database I am using?

Part of the reason why I have this question is because I don't fully understand how the storage of request.session works. Does it work like another Model? If so, how can I access the keys/items on the admin page?

Thanks for any help in advance!

Solution

  • In short: it depends on the backend you use, you specify this with the SESSION_BACKEND [Django-doc]. Te backends can be (but are not limited to):

    • 'django.contrib.sessions.backends.db'
    • 'django.contrib.sessions.backends.file'
    • 'django.contrib.sessions.backends.cache'
    • 'django.contrib.sessions.backends.cached_db'
    • 'django.contrib.sessions.backends.signed_cookies'

    Depending on how each backend is implemented, different maximums are applied.

    Furthermore the SESSION_SERIALIZER matters as well, since this determines how the data is encoded. There are two builtin serializers:

    • 'django.contrib.sessions.serializers.JSONSerializer'; and
    • ''django.contrib.sessions.serializers.PickleSerializer'.

    Serializers

    The serializer determines how the session data is converted to a stream, and thus has some impact on the compression rate.

    For the JSONSerializer, it will make a JSON dump that is then compressed with base64 compression, and signed with hmac/SHA1. This compression ratio will likely have ~33% overhead compared to the original JSON blob.

    The PickleSerializer will first pickle the object, and then compress it as well and sign it. Pickling tends to be less compact than JSON encoding, but pickling on the other hand can convert objects that are not dictionaries, lists, etc. into a stream.

    Backends

    Once the data is serialized, the backend determines where it is stored. Some backends have limitations.

    django.contrib.sessions.backends.db

    Here Django uses a database model to store session data. If the database can store values up to 4 GiB (like MySQL for example), then it will probably store JSON blobs up to 3 GiB per session. Note that of course there should be sufficient disk space to store the table.

    django.contrib.sessions.backends.file

    Here the data is written to a file. There are no limitations implemented, but of course there should be sufficient disk space. Some operating systems can add certain limitations to the amount of disk space files in a directory can allocate.

    django.contrib.sessions.backends.cache

    Here it is stored in one of the caches you specified in the CACHES setting [Django-doc], depending on the cache system you pick certain limitations can apply.

    django.contrib.sessions.backends.cache_db

    Here you use a combination of cache and db: you use the cache, but the data is backed by the database, such that if the cache is invalidated, the database still contains the data. This thus means that the limitations of both backends apply.

    django.contrib.sessions.backends.signed_cookies

    Here you store signed cookies at the browser of the client. The limitations of the cookies are here specified by the browser.

    RFC-2965 on HTTP State Management Mechanism specifies that a browser should normally be capable of storing at least 4096 bytes per cookie. But with the signing part, it might be possible that this threshold is not sufficient at all.

    If you use the cookies of the browser, you thus can only store very limited amounts of data.