WordPress.org

Make WordPress Core

Opened 9 years ago

Closed 7 years ago

Last modified 6 years ago

#20094 closed defect (bug) (fixed)

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

Reported by: mdawaffe Owned by: azaozz
Milestone: 4.0 Priority: normal
Severity: normal Version:
Component: TinyMCE Keywords: needs-patch needs-refresh
Focuses: Cc:

Description

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.

Attachments (1)

20094.diff (1.3 KB) - added by mdawaffe 9 years ago.

Download all attachments as: .zip

Change History (15)

@mdawaffe
9 years ago

#1 @mdawaffe
9 years ago

  • Summary changed from The wpEditImage TinyMCE plugin is broken when TinyMCE is served from another doain to The wpEditImage TinyMCE plugin is broken when TinyMCE is served from another domain

#2 @danielbachhuber
9 years ago

  • Cc wordpress@… added

#3 @nacin
9 years ago

Looks good at a glance here.

#4 follow-up: @azaozz
9 years ago

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.

#5 @azaozz
9 years ago

In [19977]:

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

#6 in reply to: ↑ 4 ; follow-up: @mdawaffe
9 years ago

Replying to azaozz:

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

Problem still exists :)

#7 in reply to: ↑ 6 ; follow-up: @azaozz
9 years ago

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).

#8 in reply to: ↑ 7 @mdawaffe
9 years ago

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).

#9 follow-up: @lancewillett
7 years ago

  • Keywords needs-patch needs-refresh added; has-patch needs-testing removed
  • Milestone changed from Awaiting Review to Future Release

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)

#10 in reply to: ↑ 9 ; follow-up: @lancewillett
7 years ago

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 ) {

#11 in reply to: ↑ 10 @azaozz
7 years ago

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".

#12 @azaozz
7 years ago

  • Owner set to azaozz
  • Resolution set to fixed
  • Status changed from new to closed

In 29449:

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

#13 @azaozz
7 years ago

  • Milestone changed from Future Release to 4.0

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

Last edited 7 years ago by azaozz (previous) (diff)

#14 @mdgross
6 years ago

  • Version 2.6 deleted

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.

Note: See TracTickets for help on using tickets.