Opened 12 years ago
Closed 12 years ago
#19664 closed Bug (fixed)
Illegal Characters In Session Key Give Fatal Error On File Backend Only
Reported by: | Simon Blanchard | Owned by: | Sasha Romijn |
---|---|---|---|
Component: | contrib.sessions | Version: | dev |
Severity: | Normal | Keywords: | cookies sessions |
Cc: | bnomis@…, eromijn@… | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
The file backend for sessions checks for illegal characters in the key. If there are any illegal characters it throws a SuspiciousOperation exception. It is the only backend that check for this and throws an error. Shouldn't every backend either check or none of them?
This is an issue because I occasionally get http clients accessing my sites with a comma separating cookies rather than a semicolon in the HTTP_COOKIE variable. Python parses the cookie string wrongly (according to the spec.) and I end up with a comma at the end of the first cookie. I've reported this in the Python issue tracker http://bugs.python.org/issue16362 It's known behaviour and will not be fixed.
I suspect this has not been noticed by many since not many use the file backend.
So do we really need to throw an error here. Or could we just return a new session?
Attachments (1)
Change History (10)
comment:1 by , 12 years ago
Summary: | Illegal Characters Im Session Key Give Fatal Error On File Backend Only → Illegal Characters In Session Key Give Fatal Error On File Backend Only |
---|
comment:2 by , 12 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|---|
Type: | Uncategorized → Bug |
comment:3 by , 12 years ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
by , 12 years ago
Attachment: | [Django] ERROR (EXTERNAL IP)_ Internal Server Error_ _en_.eml added |
---|
Error traceback
comment:5 by , 12 years ago
Resolution: | needsinfo |
---|---|
Status: | closed → new |
Oops, I was looking at the cache backend and not at the session backend, sorry!
comment:6 by , 12 years ago
Triage Stage: | Design decision needed → Accepted |
---|
comment:7 by , 12 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Status: | new → assigned |
Version: | 1.5-beta-1 → master |
comment:8 by , 12 years ago
All other session backends simply create a new session if there is some kind of problem with the provided session key. I think it absolutely makes sense to do this for the file backend too.
comment:9 by , 12 years ago
Has patch: | set |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Triage Stage: | Accepted → Ready for checkin |
I cannot locate any specific check in the file backend; it just calls
validate_key
from the base class.Could you clarify which check you're referring to, and provide a complete traceback?