Bug #72250
closed
Links in CE table no longer work in TYPO3 6.2.16
Added by Andreas Bigger almost 9 years ago.
Updated almost 9 years ago.
Description
With the fixing of the security issue #25245 an breaking change seems to have been introduced in the CE Table (and presumably in CE Bullets, but we do not use this CE, so I can say nothing about it):
Before 6.2.16, the following content brought the desired result:
Auskunft|<link address1@domain.ch - mail>address1@domain.ch</link>|<link 1 _self internal-link>Linktext</link>
Betriebsleitung|<link address2@domain.ch - mail>adress2@domain.ch</link>|<link 2 _self internal-link>Linktext</link>
i.e. the links got displayed as they should.
With the changes in TYPO3 6.2.16 the links are not displayed any more, because the < > are treated as entities and come out as > or <.
This seems to me a bug - or is there a workaround I do not know of?
Best wishes
Andreas Bigger
Same here with other HTML-Tags like br and - since the update to 6.2.16 these tags are rendered in FE. Worked in 6.2.15
- Status changed from New to Closed
Hi Woulter,
By introducing the following in 6.2.16
tt_content.table {
20.innerStdWrap.parseFunc >
20.innerStdWrap.htmlSpecialChars = 1
}
we are facing a lot of difficulties, since all our customers are using the link-feature in tables as Andreas is mentioning.
We find it quite drastic to completely remove the feature of linking from table cell content. Of course we can change this behaviour locally, but we would like to know wether this is something that is not due to be changed in the core.
Greetings,
Claus
I would agree to Claus' statement.
Furthermore, it seems a strange solution to a security problem: You turn off the link-feature to solve it, but tell people, they can turn the feature on again, only, then the security problem is back up and no solution in sight.
With kind regards
Andreas Bigger
All your questions are answered in the bulletin.
I'll quote them here again:
Important Note: Please pay attention that these fixes add default TypoScript settings. If you overwrite or delete the provided TypoScript for css_styled_content and/or fe_login make sure you add the htmlspecialchars function on your own. These are the TypoScript settings that need to be changed to apply proper HTML encoding to editor content:
Please note, that in case editors were allowed to edit HTML in your particular installation, that you need to adapt the TypoScript to allow HTML input again. Be aware however that your editors will have full control over HTML, which equals to having permission to create HTML content elements.
Hi again,
so basically a ~12 year old feature is now removed.
I simply cannot get my head around why parseFunc was removed from tables?
The only way the editors could create links in tables was using the syntax (<link xxx>Link</link>) and now this functionality is gone?
NB: What is the difference between the editors using the HTML CE and Table CE XSS wise?
Greetings
/Claus
Inserting the proposed Typoscript in my root template / setup doesn't show any effect. <link ../..>Text</link> in CE table still is not parsed to a link.
Could anyone explain how and possibly where exactly the script has to be inserted - thanks a lot.
Cheers
Reimer
Hi Hagen
The typoscript below fixes the issue for link in table cells in tt_content table CE:
tt_content.table{
20.innerStdWrap.parseFunc =< lib.parseFunc
20.innerStdWrap.htmlSpecialChars >
}
Greetings
Claus
@Woulter: BTW: start the table wizard with large fields, insert a linebreak there, save it -> you get a <br/> in your table that is consequently shows up as <br/> in the frontend. I think at least that should get fixed, if nothing else.
@Hagen Reimer: I do not know exactly to what you refer. The code given in https://typo3.org/teams/security/security-bulletins/typo3-core/typo3-core-sa-2015-013/ is the one that turns the link featur off. If you want to turn it back on, you have to disable the htmlSpecialChars, i.e. tt_content.table.20.innerStdWrap.htmlSpecialChars = 0 and turn on the deleted parseFunc again, i.e. tt_content.table.20.innerStdWrap.parseFunc = < lib.parseFunc - then it works, at least for us. But we have a small set of users which do not mess around with our CEs and the access to the backend is protected by other means. If you want to keep the link feature in tables and be secure from XSS in tables at the same time, then I do not know, what the solution might be. A somebody else's problem field, perhaps ;-).
(I know a bug report is not the exactly right place for helping other people with their problems, but since you asked I thought it nice to answer anyway)
Also available in: Atom
PDF