[TYPO3-core] RFC: pi_openAtagHrefInJSwindow() applies htmlspecialchars() twice
Martin Kutschker
Martin.Kutschker at n0spam-blackbox.net
Tue Nov 7 13:41:43 CET 2006
Michael Stucki schrieb:
> Martin Kutschker wrote:
>
>
>>>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.
>>
>>Not tested, but...
>>
>>If the return value of pi_openAtagHrefInJSwindow() gets hsc'd later on
>>then it won't matter if you hsc everything or only parts.
>>
>>I fail to see where the double hsc'ing occurs.
>
>
> It doesn't occur twice inside of this function, but since the input string
> ($str) is an '<a href="..">' element we can expect that it has been
> htmlspecialchar'ed.
>
> "http://typo3.org/?&test=1" => This is just a URL. There's no need that this
> is htmlspecialchar'ed because it can be used inside many more things than
> only HTML content.
>
> <a href="http://typo3.org/?&test=1">link</a> => This is HTML content: The
> output must be specialchar'ed, so this one is invalid. The correct string
> would read: <a href="http://typo3.org/?&test=1">link</a>
>
> And _this_ is the value that gets sent to pi_openAtagHrefInJSwindow()
I understand.
But what if some existing code relied on the hsc'ing in the call? I have
never used it, but the comment does not imply that the input has to be
hsc'd. OTOH, it doesn't tell about the output either.
And it's a stupid API anyway. Why is there no function that takes the URL
as argument? ;-)
Masi
More information about the TYPO3-team-core
mailing list