[Typo3-dev] RFC: Bug #277: utf-8 + JSMENU/feAdminLib

[Andreas Schwarzkopf]

Hi Bernard,

I think some major part of this problem is not addressed in your 
solution yet, it is more than only the alert problem.

An example situation:
- site with utf-8 charset
- forms with preview, based on feAdminLib.inc
- user with any modern browser, e.g. firefox 1 or IE 6.0

In this situation all non-ASCII chars entered by the user will be 
corrupted when they are stored to the database, because of this obsolete 
js function unescape.

So if you will drop the unescape/rawurlencoding, this non-ASCII 
characters will be sent to the server not encoded at all. IMHO, it is 
also not very robust and might cause some problems on servers which can 
not handle multibyte data correctly?

A very robust solution, wich I tested on production servers is the patch 
in the bugtracker: tslib_cObj.patch [^] (2,060 bytes) 12.04.05 13:22

grtx

Andreas

Bernhard Kraft schrieb:
> Hello,
> 
> 
> The Zap-the-Gremlins team tries to fix the following bug:
> 
> http://bugs.typo3.org/view.php?id=277
> 
> And I would like to have some feedback.
> 
> The problem seems to evlove from the fact that VERY OLD browsers (3.x 
> Netscape/IE) didn't support non-ASCII values
> like Umlauts öäü and as a result of this no utf-8 strings in their 
> alert('...') or similar methods. So the construct
> unescape(\''.rawurlencode($str).'\')
> was "invented".
> 
> Nowadays browsers support alert('日本語引数テストファイル') (Japanese - 
> switch your mail-client to utf-8 for this post)
> without any problems.
> 
> In these old days just the strings didn't get interpreted correctly .... 
> but the parsers were almost the same as today.
> The only thing you have to care about when you write an JS string 
> enclosed for exmplae in single quotes ' is that you
> quote any single quote in the string with a \ (backslash). i.e. 'Let's 
> rock' should become 'Let\'s rock'.
> 
> This can get achieved by using the "addcslashes" php function:
> 
> $str = 'Let\'s rock. Heres a " doublequote';     // The \' is just 
> because also php needs the ' escaped. Just a ' will get stored in the 
> string.
> $str = addcslashes($str, "'");            // Quote all '
> 
> Now you could use this string in any <script> tag:
> $out .= '<script language="JavaScript" type="text/javascript">
> alert(\''.$str.'\')
> </script>';
> 
> So this would solve all problems in tslib/class.tslib_menu.php and 
> feAdminLib.
> 
> When the String get's used in a onClick event additional measures need 
> to be taken:
> 
> The contents of an tag attribute get's feed trough the HTML parser which 
> replaces all entities (i.e.: &amp;) so you won't be happy if you want
> to have the TEXT &amp; in the alert text (not converted to &). So you 
> will first need to pass the string (or the complete onClick event) through
> htmlspecialchars:
> 
> $out .= '<a .... onClick="'.htmlspecialchars('alert(\''.$str.'\')').' 
> href="#">';
> 
> Note that the part "alert(\''.$str.'\')" didn't change at all. Just a 
> htmlspecialchars was wrapped around it.
> 
> This will produce html code like
> 
> <a ... onClick="alert('Let\'s rock Heres a &quot; doublequote')" href="#">
> 
> also if you would have used doublequotes " for quoting the alert string 
> it would be valid and look like the following:
> 
> <a ... onClick="alert(&quot;Let\'s rock&quot;)" href="#">
> 
> Which would be completly valid (first HTML entities get replaced by HTML 
> parser. Then quoted characters get replaced by their original by the JS 
> parser)
> 
> 
> So my final result is that the unescape(rawurlencode()) construct should 
> get dropped and replaced by propper quoting/specialchar'ing the text's and
> drop support for 3.x browsers.
> 
> Does someone have major arguments against this step ?
> 
> 
> 
> greets,
> Bernhard