Emoji plugin - iconsall.svg not loaded in CORS context

[sescandell]

Type of report

Bug

Provide detailed reproduction steps (if any)

When getting CKEDITOR from a domain different than the website the user is navigating on, the emoji plugin doesn't succeed to load iconsall.svg file because of domains error. Here is the detailed error sent by Chrome:

Unsafe attempt to load URL https://static.mywebsite.com/ckEditor/plugins/emoji/assets/iconsall.svg?t=IA8F from frame with URL https://www.mywebsite.com/my-page/. Domains, protocols and ports must match.

Note that a GET request to the URL https://static.mywebsite.com/ckEditor/plugins/emoji/assets/iconsall.svg?t=IA8F got the appropriate headers:

access-control-allow-headers: *
access-control-allow-methods: GET, OPTIONS
access-control-allow-origin: *

Expected result

iconsall.svg should load and Emoji Navigation Items should display.

Actual result

iconsall.svg is not loading neither Emoji Navigation Items.

Other details

• Browser: Chrome / Firefox (not tested others)
• OS: Windows (not tested others)
• CKEditor version: 4.11.1
• Installed CKEditor plugins: Emoji

[jacekbogdanski]

Hello,

I'm wondering how you managed to set request headers for emoji.json file and also iconsall.svg file? As I understand you enabled CORS for these files but still getting an error?

Note that keeping the same domain, protocol, and port between assets and application is important to prevent XSS attacks - I would strongly suggest to host CKEditor on the same domain.

[sescandell]

Hi @jacekbogdanski

Both websites are under our control. We use, for performance considerations, different domains (sub-domains to be precise) for the application and the assets (something really classic actually in web applications today). So yes, we are under control of the CORS configuration on the website serving the emoji.json and iconsall.svg files. And, for tests, we define them to allow all origins for now (but it's not working).

Actually, this is the same scenario as using your CDN except we use ours. Here is a jsfiddle to illustrate the issue: https://jsfiddle.net/u1q3hksb/. Try to click on the Emoji plugin icon (last icon in the last toolbar) and see by yourself.

Not sure to clearly understant that question:

I'm wondering how you managed to set request headers for emoji.json file and also iconsall.svg file?

We don't do anything special: just create a CKEDITOR instance, than click on the EmojiPlugin button in the toolbar. As a result, it tries to display a cke_panel with all emojis, CSS and some navigation items. Everything is working except the svg file request and so navigation items.

Thanks for your time,

[jacekbogdanski]

Now everything is crystal clear, sorry for misunderstanding and thanks for the sample. I can reproduce the issue. It looks like it exists only for SVG icons and if you run CKEditor sample on IE11 it works fine thus PNG icons fallback.

The issue is not so simple because it seems to be no easy way to include SVG from a different domain. SVG is XML based so some browsers will refuse to load it using href attribute for security reasons:

https://github.com/ckeditor/ckeditor-dev/blob/053530358ecdd9a67254e5fc6f5b527e39763bab/plugins/emoji/plugin.js#L227-L236

The only fix which currently comes to my mind is inlining SVG icons. Eventually, we can use SVG as a background image or just drop it in favor of PNG. For sure it requires some solution because except cross-domain issue when using subdomains it also breaks emoji panel with CDN.

[Comandeer]

Issue is not that hard. We already have Ajax request for emoji.json file and adding second Ajax request for SVG file shouldn't be that difficult.

[seanhudson]

Any progress on this? @jacekbogdanski you mentioned "
The only fix which currently comes to my mind is inlining SVG icons." Is that something we can implement? @Comandeer do you have a solution?

[ghost]

https://github.com/RetroWeeb/ckeditor4-cors-safe-emoji

Try this @seanhudson

[ghost]

I apparently forgot to migrate an existing variable into the new logic. That has been fixed.

[BastianBonnin]

Hello, any news on this? I'm using the CDN so unfortunately I can't use KernelZechs solution.

[ghost]

I can't believe this is still a problem a year later honestly. @BastianBonnin you could prob. attempt to double load this by loading CKEditor first and then loading this plugin manually using a local source on your web server, however I don't know if that will fix your issues. I no longer use CKEditor for anything day-to-day so I'm not of much help. Alternatively you could move away from the CDN source as it would be a simple reference change, but I don't know your setup and how restrictive it is.

[f1ames]

Fixed with 512085d.