Opened 9 years ago
Closed 9 years ago
#28155 closed Bug (wontfix)
Security system checks do not ignore MIDDLEWARE_CLASSES when MIDDLEWARE is defined
| Reported by: | Pritam Baral | Owned by: | nobody |
|---|---|---|---|
| Component: | Core (System checks) | Version: | 1.10 |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | yes | UI/UX: | no |
Description
1_10.W001 says "Since you've set MIDDLEWARE, the value of MIDDLEWARE_CLASSES is ignored"
But security system checks for session and csrf middleware check for MIDDLEWARE_CLASSES first and only if that fails do they check for MIDDLEWARE, contrary to what the compatibility system checks say.
The issue is compounded by the fact that global_settings.py defines MIDDLEWARE_CLASSES to contain two middlewares (one of which is csrf). So to disable csrf, one not only has to define MIDDLEWARE without including the csrf middleware in it, one also has to override and set MIDDLEWARE_CLASSES = []. At which point, the compatibility system check 1_10.W001 fires up.
Change History (1)
comment:1 by , 9 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
| Triage Stage: | Unreviewed → Accepted |
| Version: | 1.11 → 1.10 |
Note:
See TracTickets
for help on using tickets.
Thank you for taking the time to report this issue but I'll mark this ticket as wontfix for the following reasons.
The bug has been present since 1.10's introduction of
settings.MIDDLEWAREand at this point the 1.10 branch only receives security fixes, 1.11 only fixes for major functionality bugs in new features of the latest stable release and the master branch removed all references tosettings.MIDDLEWARE_CLASSES.Since this bug can be easily worked around by silencing
1_10.W001and that disabling CSRF protection is uncommon and discouraged I don't think it warrants a backport to 1.11.