Data integrity issue with sending all meta data to the browser page

And to top it off, entity type + bundle + field name AREN'T sent to the media browser page! So no last-minute on-the-fly field-specific customization possible. That's not a bug, but still... It is a shame.

The most important parts for me are (both Dave's):

• "the Media browser is also used in a non-field context and we do not always have entity type/bundle/field name available" -- when is that?
• "a reliable way to add any kind of checksum/token protection against the serialized options"

When is the media browser ever used in a non-field/entity context? A form propagating #type => managed_file doesn't open the media browser. (Or does it? I can't find it.)

A reliable way to add a checksum or token shouldn't be necessary. The parameters should always be 'public': entity type + bundle + field name. If you have only that as meta data, you can't cheat. Ever. In any way. Even if you use [a+b+C] meta data for a [a+D+E] field, you can only upload it to field [a+b+C], because the field validate will have the exact same context as the field render function (where the params are collected currently, I don't know where).

@greggles My account's options are irrelevant, because I am an admin in some Domain contexts and only a user in other contexts. It's dependent on only 2 things: entity + bundle + field and (field value) delta. A lonesome user should be able to upload a file where a super admin shouldn't. And the opposite. But that's beside that the point. The most important thing IMO:

"the Media browser is also used in a non-field context and we do not always have entity type/bundle/field name available"

If I knew how, I could try to reproduce and tackle that part.

Since I do consider myself a programmer, the most relevant part of this topic (already) is: "You can always roll a patch and get it fixed ;)" and Yes I Will. If Dave tells me how to open the media browser in a non-field context, I will tackle the shit out of it!

It's not security as in taking over the server or even XSS, but an admin could interpret it like that when a user can upload files where they shouldn't be able to, by 'hacking' this module.

"Data integrity issue" does word it better.

I'm looking into it.

That was relatively simple. Media 2 is much nicer than media 1.

Attached patch:

* doesn't add meta data to JS settings
* does add entity_type, bundle_name and field_name to JS settings
* uses those in media_set_browser_params() to fetch the field instance and its media browser settings (using a new function media_get_field_media_browser_settings() that's used in media_field_widget_form() as well)
* changes what JS sends to the media browser page (I've removed params.plugins because it's never ever used in PHP or JS) so it's now a clean, lovely URL: media/browser?render=media-popup&entity_type=node&bundle_name=page&field_name=field_medium

The already existing alter (media_browser_params) is now actually useful. I can do this:

function YOURMODULE_media_browser_params_alter(&$params) {
	// Is a wysiwyg.
	if (empty($params['field_instance']) || in_array($params['field_instance']['widget']['type'], array('text_textarea_with_summary', 'text_textarea'))) {
		// Remove upload plugin.
		if (!empty($params['enabledPlugins'])) {
			unset($params['enabledPlugins']['upload']);
		}
		else {
			$plugins = media_get_browser_plugin_info();
			$params['enabledPlugins'] = drupal_map_assoc(array_keys($plugins));
			unset($params['enabledPlugins']['upload']);
		}
	}
}

There's still a few issues (that I can't include in the patch)

* Actual validation: I can still change the URL to point to a different field, so I can still upload a file. I'm not sure where to add that validation..?
* The WYSIWYG logic is somehow handled by ckeditor.module and not by media.module (which is weird in itself) so I can't send entity+bundle+field with, so you never know for which field the media button was pushed. If media.module would handle the wysiwyg plugin (like it's supposed to?) I could've added that.

There's only one case that really doesn't have field context: a lonesome wysiwyg, not in an entity form. (Any form can have a wysiwyg that has the media button.) No context possible there. In all other cases, there's always a field, so the params alter should always have hat context. (With this patch it does for file fields, but not for wysiwyg fields.)

The actual validation needs discussion and work, but this is a very nice start IMO.

Oh, btw:

we do not always have entity type/bundle/field name available and rely on the global settings, so it can't just go away

There aren't any global settings? The wysiwyg meta data would be completely empty and all plugins are shown...

removing unnecessary passion