Opened 12 years ago
Closed 12 years ago
#22711 closed defect (bug) (fixed)
Only show Delete in media modal if the user can delete
Reported by: | nacin | Owned by: | ryan |
---|---|---|---|
Milestone: | 3.5 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Media | Keywords: | has-patch commit |
Focuses: | Cc: |
Description
Patch attached.
Attachments (4)
Change History (12)
#2
@
12 years ago
I'm still seeing a "Saved" notice as an Author (though it does not actually appear to save). The delete button appears to be working properly and being hidden when it can't be used.
#4
@
12 years ago
Here's an audit (with patch) —
wp_ajax_send_link_to_editor - nonce. no cap check, no object to act on.
wp_ajax_send_attachment_to_editor - nonce. no cap check normally. edit_post cap check for attaching an unattached item. attachment post type check.
wp_ajax_save_attachment_order - nonce, edit_post cap check for the post things are attached to, and edit_post on each attachment (with post type check). same as 3.4. (which included the possibility of only some of the menu order saving, if you could only edit some attachments.)
wp_ajax_save_attachment_compat - nonce, edit_post cap check. attachment post type check.
wp_ajax_save_attachment - nonce, edit_post cap check. attachment post type check.
wp_ajax_query_attachments - generic upload_files cap check. private_posts cap check to see if private attachments should be included. no nonce as it is a get. no edit_post or read_post cap check as a user does not need to be able to edit or read an attachment's parent (under "inherit" rules) to be able to view and insert said attachment in 3.4.
wp_ajax_get_attachment - generic upload_files cap check. attachment post type check. no nonce as it is a get. no edit_post or read_post cap check as a user does not need to be able to edit or read an attachment's parent (under "inherit" rules) to be able to view and insert said attachment in 3.4.
#6
@
12 years ago
Latest triggers fail handlers when the nonces are not present, adds error handling to the attachment saving UI, and marks fields as read only when appropriate.
Did some testing for both editing and deleting as both an Administrator and an Author, as an Author is the lowest permission allowed. Looks like we can tighten the cap checks in some places (querying) and loosen them elsewhere (inserting).
We need to make sure not to save an attachment when we're not allowed to, but still allow caption etc. to be edited before it gets inserted. Having split XHR handlers for save versus insert makes this particularly nice. 22711.2.diff