Sessions are unnecessarily complex
|Reported by:||Paul McMillan||Owned by:||Paul McMillan|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
Django includes several backends for storing session data. None of these store data in a manner that is accessible to clients. The backends rely on trusted infrastructure: the database, the cache, or the filesystem.
For all of recorded history (since the earliest svn checkins), Django has stored session data in an obfuscated format. We pickle the data, hash it, and store the hash + base64(data). To retrieve session data, we do the opposite: pull the string from our trusted backend, hash the data, compare to the stored hash, and then if it matches, return it.
My best guess is that this is a holdover from an earlier era when Ellington stored session data client side in cookies. None of the default backends support this, and it may not currently be possible.
This means that we are running significant extra code every time we hit the session store. We trust the supplied backends, but we don't know that a user hasn't subclassed the base backend to depend on this hashing behavior.
I propose that we rework the base backend to include an
InsecureSessionBase which our provided backends subclass. This new class will provide simple key/value behavior without the hashing. We will retain the current hashing behavior in the
SessionBase class for backwards compatibility, and it will inherit from
InsecureSessionBase for all other methods.
Change History (5)
comment:1 Changed 6 years ago by
|Patch needs improvement:||unset|
|Triage Stage:||Unreviewed → Accepted|