Opened 19 years ago
Closed 18 years ago
#1979 closed enhancement (wontfix)
[patch] Modify debug.py to show database queries on 500 errors
Reported by: | Owned by: | Adrian Holovaty | |
---|---|---|---|
Component: | Core (Other) | Version: | |
Severity: | normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Patch to list any database queries that have been executed ( i.e. stored in django.db.connection.queries ) in a 500 Internal Server Error.
Attachments (1)
Change History (6)
by , 19 years ago
Attachment: | debug_queries.diff added |
---|
comment:1 by , 19 years ago
comment:2 by , 19 years ago
I'm not sure this is a good idea: it's a possible security hole. I've seen way too many public-facing Django sites with DEBUG set to True, which gives the public access to the debug pages, so I'd rather not display raw database queries in the debug error pages.
Maybe, as a compromise, the queries could be displayed only for requests from localhost? Or would that defeat the purpose?
comment:3 by , 19 years ago
Adrian: I didn't think of that, but the entire Debug output is a security hole on a production website anyway - path info, cookie info, session id's, the region of code that died, etc are all listed. If anyone's stupid enough to run a production website with Debug turned on, then they kind of deserve what they get.
However, either locking it down to localhost only, or maybe have a setting to enable it (default -> disabled)?
comment:5 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Maybe we just want to trim this to the last three, five or ten queries? The connection.queries list could be hundreds of elements long, even in development.