[TYPO3-core] RFC: pi_openAtagHrefInJSwindow() applies htmlspecialchars() twice
Ernesto Baschny [cron IT]
ernst at cron-it.de
Tue Nov 7 14:27:40 CET 2006
Michael Stucki schrieb:
> This is a SVN patch request.
>
> Problem:
> The input string for pi_openAtagHrefInJSwindow() needs to be an complete <a
> href=.."> element, so it is clear that this must have htmlspecialchars()
> applied. However, when sending out the resulting JavaScript link, the whole
> content is sent through htmlspecialchars() again.
>
> Solution:
> I have removed the htmlspecialchars() call around the full output string but
> added two new ones for $winName and $winParams only.
>
> Branches: TYPO3_4-0 and Trunk
I agree that this is a problem, but the current code might have been
taken as a "documentation" and the callers might have not called hsc
before handing the <a> tag to this function.
If I call (as I would until 4.0.2):
pi_openAtagHrefInJSwindow('<a href="index.php?id=1&test=1">');
Without the patch I get:
<a href="#"
onclick="vHWin=window.open('http://<domain>/index.php?id=1&test=1','2354235','');vHWin.focus();return
false;">
After the patch I get:
<a href="#"
onclick="vHWin=window.open('http://<domain>/index.php?id=1&test=1','2354235','');vHWin.focus();return
false;">
So clearly the second one is not XHTML-conform.
So I would propose to change it only in TRUNK and have that notice added
in the release notes so that plugin writers can check if their extension
is affected and change it accordingly. Or do the "TYPO3-way", which
would be to add a $hsc parameter to the function, where the caller can
decide if he wants to pass the URL again through hsc or not (defaulting
to "true" for backwards compatibility reasons).
And while changing that, we could also change the "#" to the called URL,
which would add a bit more accessibility to this call (so browsers
without active JavaScript would still be able to follow the link).
Cheers,
Ernesto
More information about the TYPO3-team-core
mailing list