meta_form() should place some restrictions on meta keys

[nacin]

meta_form() echoes out all meta keys into a dropdown for the custom fields box, unless they start with an underscore (as bound by the query).

We should consider is_protected_meta( $key, 'post' ) and/or current_user_can( 'add_post_meta', $post->ID, $key ). This isn't a security thing, just an opportunity to hide some things from the user they don't need to see.

On the other hand, it's definitely a number of extra calculations. is_protected_meta() is light as long as there's no filter on things (and if there is, we probably want to know). current_user_can() might be a bit more weight than necessary here.

[mdawaffe]

+1 for either. We shouldn't show is_protected_meta keys.

[macbrink]

+1 for at least is_protected_meta

If a filtered protected meta appears in the dropdown list, and a user selects and adds this field, he will see a very confusing message:

An unidentified error has occurred

[nacin]

In 23534:

Ignore protected meta keys in meta_form(). see #18786.

[georgestephanis]

Are we good to close this? The only thing I can think of in this would be whether it would eventually need to take custom post types into account for protected meta keys, but that's not an immediate concern if at all.

[nacin]

I'm still wondering if we should also use the current_user_can() checks. I haven't had time to profile this. Going to punt this to 3.7.

[wonderboymusic]

these are all marked 3.7-early

[nacin]

#25189 was marked as a duplicate.

[nacin]

I never noticed that meta_form() actually has a LIMIT (of 30 by default) for the number of keys it queries. So that should mean we're not calling current_user_can() too much.

[nacin]

In 25591:

Ignore unauthorized meta keys in meta_form(). fixes #18786.