Project

General

Profile

Actions

Bug #65705

closed

baseURL determination of EXT:rtehtmlare fails in edge case

Added by Lorenz Ulrich about 9 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
RTE (rtehtmlarea + ckeditor)
Target version:
-
Start date:
2015-03-12
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

The RTE has a client-side method of determining the baseURL. The baseURL is later used for loading additional resources (e.g. custom CSS). It first tries to use the document.baseURI property (which isn't present in IE), with fallbacks to the base href in the content and the whole URL. To ensure that the baseURL is only the path to the TYPO3 installation (without a document or arguments), a Regex rule is then applied to extract the path to TYPO3:

if (this.baseURL && this.baseURL.match(/(.*\:\/\/.*\/)[^\/]*/)) {
    this.baseURL = RegExp.$1;
}

This works perfectly for standard URLs such as https://mydomain.tld/typo3/alt_doc.php?foo=bar; the RegExp returns https://mydomain.tld/typo3/.

But if the URL of the page contains another fully qualified URL, the Regex fails and the whole URL is taken. For https://mydomain.tld/typo3/alt_doc.php?returnUrl=https://mydomain.tld/typo3/something.php, the whole input string is returned. This leads to a wrong baseURL and makes the browsers (tested: Firefox) fail to load the resources.

The Regex needs to be improved.


Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Bug #65608: BaseURL is wrong in Frontend when using RealURL with config.absRefPrefixClosed2015-03-09

Actions
Related to TYPO3 Core - Bug #79568: baseURL determination of EXT:rtehtmlarea fails in frontend editingClosed2017-01-31

Actions
Actions #1

Updated by Lorenz Ulrich about 9 years ago

Steps to reproduce:

Enter this in the JavaScript console of the browser:

"https://mydomain.tld/typo3/alt_doc.php?foo=bar".match(/(.*\:\/\/.*\/)[^\/]*/);
RegExp.$1;

Result: https://mydomain.tld/typo3/ (as expected)

Enter this in the JavaScript console of the browser:

"https://mydomain.tld/typo3/alt_doc.php?returnUrl=https://mydomain.tld/typo3/something.php".match(/(.*\:\/\/.*\/)[^\/]*/);
RegExp.$1;

The full input URL is returned.

Solution:

"https://mydomain.tld/typo3/alt_doc.php?returnUrl=https://mydomain.tld/typo3/something.php".match(/^((http[s]?):\/)?\/?([^:\/\s]+)((\/\w+)*\/)([\w\-\.]+[^#?\s]+)(.*)?(#[\w\-]+)?$/);
RegExp.$2 + '://' + RegExp.$3 + RegExp.$4;

This returns https://mydomain.tld/typo3/ as expected.

Actions #2

Updated by Gerrit Code Review about 9 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/37799

Actions #3

Updated by Lorenz Ulrich about 9 years ago

Steps to reproduce in TYPO3:

  • Log in to the backend.
  • Open a record and open the TCEFORM frame in a new tab.
  • Open the developer tools of your browser.
  • Change the URL so you have a fully URL in the returnURL, e.g. https://my.tld/typo3/alt_doc.php?returnUrl=http://my.tld/typo3/index.php&edit[tt_content][19057]=edit
  • Note the log record: RTE[data_tt_content__19057__bodytext_][HTMLArea.Iframe::createHead]: Iframe baseURL set to: https://my.tld/typo3/alt_doc.php?returnUrl=http://my.tld/typo3/

This doesn't lead to a problem in Chrome because it obviously can handle this, but in Firefox your custom rte.css won't be loaded anymore.

After applying the patch, the baseURL is correctly set to https://my.tld/typo3/.

Actions #4

Updated by Urs Braem almost 9 years ago

Hi!
Sorry, I can't find typo3/sysext/rtehtmlarea/Resources/Public/ at all in the 6.2.12 core. (I wanted to try patching typo3/sysext/rtehtmlarea/Resources/Public/JavaScript/HTMLArea/Configuration/Config.js) What did I get wrong?

Also, I experience the following behaviour: when trying to edit any external link with the RTE, I get our website's 404 page in the element browser's iframe. That's why I associated it with a baseURL issue. But a client gets the targetted URL in the same iframe. Could this be related with this issue at all?

Actions #5

Updated by Benni Mack over 8 years ago

  • Status changed from Under Review to Needs Feedback

Please rework. I abandoned the patch since there is no feedback. Please let me know if the problem still exists in master / 7 LTS.

Actions #6

Updated by Riccardo De Contardi about 8 years ago

  • Status changed from Needs Feedback to Closed

No feedback within the last 90 days => closing this issue.

If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.

Thank you

Actions

Also available in: Atom PDF