#21911 closed Bug (fixed)
Admin login can cause data loss
Reported by: | Raymond Penners | Owned by: | nobody |
---|---|---|---|
Component: | contrib.admin | Version: | dev |
Severity: | Release blocker | Keywords: | |
Cc: | raymond.penners@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Prerequisites: plain Django project with admin enabled, no CSRF middleware
To reproduce:
- Open up a browser, make sure you are not logged in
- Open up two tabs, both visiting: /admin/sites/site/add/
- You should be presented with a login form in both tabs.
- Login in tab 1).
- Switch to tab 2), also login.
Expected result:
- You end up at /admin/sites/site/add/ via a GET request
Actual result:
- the login as part of login at 2) fires its POST data at the /admin/sites/site/add/ view,
(proven by the fact that you will see validation errors)
Now, while in this case the actual result may seem rather harmless, we have had an incident where somebody unknowingly destroyed precious data by doing this. This may happen if the URL belongs to an update URL, and, the form happens to be considered valid (e.g. if no fields are required you will essentially blank out the model you are updating).
Why doesn't the staff_member_required decorator use redirects to redirect to separate login view, with next=/admin/sites/add ?
Change History (10)
comment:1 by , 11 years ago
Severity: | Normal → Release blocker |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 11 years ago
Cc: | added |
---|
comment:3 by , 11 years ago
Currently, the staff_member_required
decorator allows to post login data to any admin view to log in a user. I am not a fan of this functionality, but changing this would have to be documented as a backwards incompatibility.
This is mainly tested in SecureViewTests.
comment:4 by , 11 years ago
Has patch: | set |
---|---|
Needs documentation: | set |
comment:5 by , 11 years ago
Needs documentation: | unset |
---|---|
Version: | 1.4 → master |
I've updated the PR with release notes.
comment:6 by , 11 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:7 by , 11 years ago
Triage Stage: | Ready for checkin → Accepted |
---|
I've just pushed a third commit to the pull request, as I think that the this_is_the_login_form
field from the admin authentication form is now of no use.
May i have a quick review for that last point? (tests do pass with SQLite/Python 2.7)
https://github.com/claudep/django/commit/7b164cd5121608cac146ecc9d432d516a3b220d5
comment:9 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
This is concerning; data loss is never an acceptable outcome. Marking release blocker on that basis.