#29502 closed Bug (fixed)
AutocompleteJsonView doesn't work if user has "view" but not "change"
Reported by: | Matthew Frazier | Owned by: | Carlton Gibson |
---|---|---|---|
Component: | contrib.admin | Version: | 2.1 |
Severity: | Release blocker | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
If a ForeignKey
to a model is in autocomplete_fields
and the user has the view
permission but not change
, then the autocomplete field doesn't work - the view returns 403 errors, and so the field shows "The results could not be loaded." The value that was already on the model will be retained when the model is saved, but if the model is new and the field is required, this prevents the user from saving the model.
The fix is probably as simple as changing has_change_permission
to has_view_permission
on line 52 of django/contrib/admin/views/autocomplete.py
Attachments (1)
Change History (7)
by , 7 years ago
Attachment: | Django bug report - autocomplete.png added |
---|
comment:1 by , 7 years ago
Severity: | Normal → Release blocker |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 7 years ago
Has patch: | set |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:3 by , 7 years ago
To deal with the inconsistency you mentioned, the autocomplete view for a model could accept query arguments: for_app=[APP]&for_model=[MODEL]&fk=[FOREIGN_KEY]
. If those arguments are present it would look up the ModelAdmin
for the indicated app and model, verify that the user has_add_permission
or has_change_permission
on the indicated model, and verify that fk
refers to the model being autocompleted.
This would allow a ForeignKey
to work the same way whether it was in autocomplete_fields
or not, but it would make the patch more involved. It also introduces a slight security risk: if a model A
has a ForeignKey
to another model B
, then the user can still look up the values of B
even if the ModelAdmin
to A
doesn't permit them to edit the ForeignKey
to B
.
Another option that eliminates that security risk, but increases complexity even more, is to store the models a user needs access to autocomplete in their session. That is probably too much work with too much potential security exposure to include in 2.1.0 since the beta is supposed to go out today.
comment:4 by , 7 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
OK, yes. Thanks for the report.
This should probably be weakened to
view
orchange
. (Although,change
currently impliesview
.)It might be worth an addition to the
autocomplete_fields
docs, noting that the permission to the related object is required.(There's a slight inconsistency in that no permission to the related model is needed if you don't use autocomplete.)