Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42240
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 80.190.230.99 as permitted sender)
To: "'Mark Karpeles'" <mark@hell.ne.jp>,
	"'PHP Developers Mailing List'" <internals@lists.php.net>
References: <2D85B33E-889B-4214-9BB8-A12EFFFC641E@macvicar.net> <1229150500.30719.201.camel@localhost>
Date: Sat, 13 Dec 2008 22:44:20 +0100
Message-ID: <4BA26FE8A9634178B4CEBEFA818810D2@VEGA>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Aclc7fCTghJ2p56TT/q6Lq8wkdUY/QAfQpUw
In-Reply-To: <1229150500.30719.201.camel@localhost>
Subject: RE: [PHP-DEV] Removing basic types from our JSON parser
From: thetaphi@php.net ("Uwe Schindler")

> For reference I saw people use json_encode() to pass a string to
> javascript into their page while avoiding bugs/XSS with stuff like
> </script>.
> 
> var foo = <?=json_encode($my_string)?>;
> ... (yes, they maybe heared somewhere that JSON is *not* javascript, I
> told 'em too).

This is not correct. JSON *is* valid JavaScript, but the other way round is
not correct. Not every Javascript is JSON. So it is perfectly legal, to do
this.

I think, this is really cool, using json_encode() as something like
"htmlspecialchars" for correctly encoding strings inside JS for security. I
use it, too.

To the problem with basic types: I like the way of maybe giving a option to
the function. If you want to be standards conformant, you have to remove the
encoding parameter (which is also there), too. JSON has to be UTF-8, if you
want to be conform to the specs. But for the example above (secure encoding
of JS strings with json_encode), it is perfectly legal to use another
encoding (in the above case, the encoding of the HTML page).

Uwe