Bug #23474
closed
includeCSS path-string pass htmlspecialchars twice
0%
Description
There is an issue by including an external CSS file with parameters. I use it in a ViewHelper class in this way:
$GLOBALS['TSFE']->pSetup[$position][$key] = $path;
$GLOBALS['TSFE']->pSetup[$position][$key . '.'] = array(
'media' => $media,
[…]
);
$path looks like:
http://localhost/?type=123456788&cHash=a7a8da9a0538718db5b98d003bfedd6e […]
The output is:
http://localhost/?type=123456788&cHash=a7a8da9a0538718db5b98d003bfedd6e […]
You'll see the path-string pass htmlspecialchars twice:
1. class.tslib_pagegen.php line 546
2. class.t3lib_pagerenderer.php line 1105
solution replace in class.tslib_pagegen.php line 546
htmlspecialchars($ss),
to
$ss,
lg ad
(issue imported from #M15587)
Files
Updated by Mikkel Ricky over 13 years ago
Uploaded patch for resolving issue.
in "typo3/sysext/cms/tslib/class.tslib_pagegen.php" all htmlspecialchars calls are removed from method calls to
- t3lib_PageRenderer::addCssFile
- t3lib_PageRenderer::addJsLibrary
- t3lib_PageRenderer::addJsFooterLibrary
- t3lib_PageRenderer::addJsFile
- t3lib_PageRenderer::addJsFooterFile
In "t3lib/class.t3lib_pagerenderer.php" additional htmlspecialchars calls are added when rendering html output.
Updated by Steffen Gebert over 13 years ago
But isn't the & supposed to be replaced by & in the output?
So I think it would be okay to remove the htmlspecialchars() in t3lib_pagegen (to handle URLs in PHP without escaped &), but not in t3lib_PageRenderer, as output should be escaped.
All without testing, so just my assumption.
Updated by Mikkel Ricky over 13 years ago
The patch only removes calls to htmlspecialchars() in typo3/sysext/cms/tslib/class.tslib_pagegen.php.
htmlspecialchars() are still used in "t3lib/class.t3lib_pagerenderer.php" when rendering the actual html output, and the patch adds htmlspecialchars() around all attribute values when rendering the output.
For all practical purposes it shouldn't be necessary to send e.g. "media" and "type" attribute values though htmlspecialchars(), but it's better to be safe than sorry.
Updated by Steffen Gebert over 13 years ago
Ah, sorry.. today the patch looks different than last night, I swear :D
Makes sense I think.
Updated by Steffen Kamper over 13 years ago
Committed to svn
4_4 rev 9292
trunk rev 9293
Updated by