EZEE-3030: Links containing 'ezlocation` or 'ezcontent' keywords break RTE validation on paste

[konradoboza]

Question	Answer
Tickets	EZEE-3030
Bug fix?	yes
New feature?	no
BC breaks?	no
Tests pass?	yes
Doc needed?	no
License	GPL-2.0

The recently introduced solution #1245 is missing proper checks for ezcontent and zezlocation keywords that results in http protocol wrongly added, hence broken validation. Added proper conditions and flatten existing ones to increase readability. I will create a PR in ezplatform-richtext for 3.0 once this solution is approved.

Checklist:

• Coding standards ($ composer fix-cs)
• Ready for Code Review

[tomaszszopinski]

QA Approved on eZ Platform EE v2.5.9 (patch) and on eZ Platform EE 2.5 with diff.

[lserwatka]

You can merge it up.

[konradoboza]

Done.

[andrerom]

@konradoboza Doesn't these links also use scheme format, i.e. ezlocation://
If so, maybe the code should rather detect existing scheme before adding one using regex?
Secondly, what about relative urls?

[konradoboza]

@andrerom all the occurrences of ezlocation or ezcontent are validated already, ref: https://github.com/ezsystems/ezplatform-admin-ui/pull/1283/files#diff-ab42d417cb34dabef37b3c2d017e4e8bR420. That being said, scheme formats that you mentioned should be fine. What scenario of relative URLs you have in mind? As far as I can see all URLs like test.com or content/location/67 are prefixed with the protocol on publishing anyway.

[andrerom]

OK, then we should be fine, I was just unsure if this keyword matching might have still some uncovered cases or url types.

[maikfr]

Hello all,

we are using the latest 1.5.x tag of this project. Unfortunately the merge-commit from this pull request is not available there, but only in the branch itself. Would it be possible to release a new 1.5 tag with the latest changes of the appropriate branch, to be able to receive the bugfix from this pull request?

Thanks for your effort and help!

[konradoboza]

Hi @maikfr. The ezplatform-admin-ui package will be released most likely as a part of the new 2.5.10 release of eZ Platform. Not sure when this happens though, ping @lserwatka.

For now, you can apply the following diff to take advantage of this fix:

diff --git a/src/bundle/Resources/public/js/scripts/fieldType/base/base-rich-text.js b/src/bundle/Resources/public/js/scripts/fieldType/base/base-rich-text.js
index 9bc8bbd58..dbe15db35 100644
--- a/src/bundle/Resources/public/js/scripts/fieldType/base/base-rich-text.js
+++ b/src/bundle/Resources/public/js/scripts/fieldType/base/base-rich-text.js
@@ -398,17 +398,31 @@
             const links = container.querySelectorAll('a');
             const anchorPrefix = '#';
             const protocolPrefix = 'http://';
+            const restrictedKeywords = ['ezcontent', 'ezlocation'];
 
             links.forEach((link) => {
                 const href = link.getAttribute('href');
                 const protocolPattern = /^https?:\/\//i;
+                const protocolHref = protocolPrefix.concat(href);
 
-                if (href && href.indexOf(anchorPrefix) !== 0 && !protocolPattern.test(href)) {
-                    const protocolHref = protocolPrefix.concat(href);
+                if (!href) {
+                    return;
+                }
+
+                if (href.indexOf(anchorPrefix) === 0) {
+                    return;
+                }
 
-                    link.setAttribute('href', protocolHref);
-                    link.setAttribute('data-cke-saved-href', protocolHref);
+                if (protocolPattern.test(href)) {
+                    return;
                 }
+
+                if (restrictedKeywords.some((keyword) => href.includes(keyword))) {
+                    return;
+                }
+
+                link.setAttribute('href', protocolHref);
+                link.setAttribute('data-cke-saved-href', protocolHref);
             });
         }
     };