#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
vieworchange. (Although,changecurrently impliesview.)It might be worth an addition to the
autocomplete_fieldsdocs, 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.)