The wpEditImage TinyMCE plugin is broken when TinyMCE is served from another domain

[mdawaffe]

If TinyMCE is served from another domain (for example a CDN), the wpEditImage plugin tries to open the image editing iframe from that other domain. This breaks inter-iframe communication due to a violation in the same-origin policy.

The code is the same all the way back to 2.6, but I didn't verify the problem occurs there (TinyMCE's API may have changed since then).

Attached:

• Ensures the iframe is always served from the same origin as the parent page.
• Fixes the iframe cache busting.

[nacin]

Looks good at a glance here.

[azaozz]

Was planning to switch from thickbox to a native MCE popup there which would also (probably) fix the same-origin violation. Lets commit that first and if this problem still exists, can patch it then.

[azaozz]

In [19977]:

Use native TinyMCE popup for the image properties dialog, fixes #20096, see #20094

[mdawaffe]

Replying to azaozz:

Lets commit that first and if this problem still exists, can patch it then.

Problem still exists :)

[azaozz]

Replying to mdawaffe:

Problem still exists :)

In this case we would probably need to patch all TinyMCE popups/dialogs. In the default configuration there are six of them: font color/color picker, paste as text, paste from word, special characters, help and the image properties.

I vaguely remember something about cross-domain hack for MCE, perhaps there's a setting we can use to turn that on (will investigate further).

[mdawaffe]

Replying to azaozz:

In this case we would probably need to patch all TinyMCE popups/dialogs. In the default configuration there are six of them: font color/color picker, paste as text, paste from word, special characters, help and the image properties.

Confirmed that these other iframe based dialogs also break (though if image properties is different than the wpEditImage dialog, I don't know where to find it).

[lancewillett]

Tested this a bit today to see if the reported issue is still valid.

The image controls are working as expected, probably invalidated by the upgrade to TinyMCE 4.0.x, see r26876. Serving files from other domains (like a CDN) is working as expected now with images, special characters, paste as text, and image properties.

The only JS error I could get is with the Help dialog. It appears as expected, but I do see this error in the console (domains redacted a bit as an example):

Uncaught SecurityError: Blocked a frame with origin "https://some.cdn.com" from accessing a frame with origin "https://actualwebsite.com". Protocols, domains, and ports must match. wp-mce-help.php:77
(anonymous function)

[lancewillett]

Replying to lancewillett:

The only JS error I could get is with the Help dialog.

Above error is in Chrome 36.0.x on OS X 10.9.4. In Firefox 31.0 on same OS I see:

Error: Permission denied to access property 'tinymce'
wp-mce-help.php()wp-mce-help.php (line 77)

if ( win && win.tinymce && win.tinymce.isMac ) {

[azaozz]

Replying to lancewillett:

Yeah, this only happens for iframe based modals. All "native" modals in TinyMCE 4.0 are build from JS, the only remaining we have is the Help/Keyboard Shortcuts one. We should fix that call to the parent to make it fully "independent".

[azaozz]

In 29449:

TinyMCE: don't access the parent window when opening the (iframe based) Help/Keyboard Shortcuts modal. Fixes #20094.

[azaozz]

With this all TinyMCE modals used in WordPress can be loaded from a different domain/CDN.

[mdgross]

I think this may be related. We have defined the following in wp-config.php

define('WP_CONTENT_DIR', '/var/www/vhosts/cdn.domain.com/wp-content');
define('WP_CONTENT_URL', 'http://cdn.domain.com/wp-content');

We have also created a custom TinyMCE button

add_filter('mce_external_plugins', array($this, 'add_tinymce_plugin'));
add_filter('mce_buttons', array($this, 'register_tinymce_button' ));

The button is appearing but fails when clicked. According to console:

Error: Permission denied to access property "tinymce"
tinymce = tinyMCE = parentWin.tinymce;

I believe this is happening because WordPress is being served from ​http://www.domain.com but the popup is being served from ​http://cdn.domain.com. It works perfectly without WP_CONTENT_URL and WP_CONTENT_DIR. Please advise.