Path: csiph.com!news.mixmin.net!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: Thomas 'PointedEars' Lahn <PointedEars@web.de>
Newsgroups: comp.lang.javascript
Subject: Re: How to pass a php variable to a javascript file (function)?
Date: Sat, 03 Oct 2015 04:35:06 +0200
Organization: PointedEars Software (PES)
Lines: 191
Message-ID: <13501800.DmYS3OLCIa@PointedEars.de>
References: <r6jPx.32747$nl4.14152@fx02.am4> <XnsA5276328DD4DEeejj99@194.109.6.166> <mulldu$lli$1@news.albasani.net> <1739227.XXYPReGQTy@PointedEars.de> <mun0p1$d9i$3@news.albasani.net>
Reply-To: Thomas 'PointedEars' Lahn <cljs@PointedEars.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8Bit
X-Trace: solani.org 1443839707 23541 eJwFwYEBACAEBMCVkH81jsT+I3SHRWWFE3QMxsefNc+OfVgyckwiW6tEL5EChXW+0Ll7pX4Q6xDI (3 Oct 2015 02:35:07 GMT)
X-Complaints-To: abuse@news.solani.org
NNTP-Posting-Date: Sat, 3 Oct 2015 02:35:07 +0000 (UTC)
User-Agent: KNode/4.14.2
X-User-ID: eJwFwYEBwCAIA7CXUEqZ5yiU/09YEs7FSjCImBja4xRPNr65W1o5byAvOdIE3FZelYiy1mEGDLV7H1X7D3iwFo8=
Cancel-Lock: sha1:fUPpNwbVozudrupWaaMyHImkzxE=
X-NNTP-Posting-Host: eJwNwoERACEIA7CVrNIK4wji/iP8X8IlqLaJMr4fOP31ObqKGxPRxElLru3Dkas4Q410lGx8EvsQcw==
Xref: csiph.com comp.lang.javascript:28804

Stefan Weiss wrote:

> On 2015-10-02 21:37, Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> That doesn't mean that json_encode() by itself is enough to safely
>>> escape strings as JavaScript literals. What if $sometext contains
>>> "</script>"?
>> Not a problem in HTML5 or XHTML(5), but in HTML < 5.
> 
> That is incorrect, see below.

My description is not incorrect, but incomplete.
 
>>> | Note: The easiest and safest way to avoid the rather strange
>>> | restrictions described in this section is to always escape "<!--" as
>>> | "<\!--", "<script" as "<\script", and "</script" as "<\/script"  […]
>> 
>> And it is wrong *again* (see below).  For example, if you had a RegExp
>> literal in your ECMAScript or Perl code to match “<script” (which as for
>> ECMAScript code can be useful for retrieving embedded data), which would
>> likely be /<script…/, then changing that to /<\script…/ would attempt to
>> match “<”, followed by ECMAScript/Perl whitespace, followed by “cript…”
>> instead.
> 
> What the hell are you rambling about? Nobody said anything about Perl
> regexes.

Yes, the problem is yet another knee-jerk assertion in yet another HTML 
Specification note.  There is no regard in it as to how script code is 
generated, and as to what script code is intended to do.

> I wrote (quoted) that "<script" should be replaced with
> "<\script".

Which is wrong *in general*, as I have pointed out.

This assertion is in the same sense wrong as is the following one further 
below the Specification prose, in another note:

| It is possible for these sequences to naturally occur in script 
| expressions, as in the following examples:
| 
| if (x<!--y) { ... }
| if ( player<script ) { ... }
| 
| In such cases the characters cannot be escaped, but the expressions can be 
| rewritten so that the sequences don't occur, as in:
| 
| if (x < !--y) { ... }
| 
| […]
| [as] for related historical reasons, the string "<!--" in JavaScript is 
| actually treated as a line comment start, just like "//".

No, it is not.  The problem here is that the authors make the common mistake 
and use the term “JavaScript” as an umbrella term, failing to differentiate 
between ECMAScript implementations. [1]  They also fail to differentiate 
between markup parsers’ preprocessing and the parsing of script engines.

And again, instead of modifying your script code to accomodate markup 
languages in which it is contained, you are much better off by taking the 
offending script code out of the problematic markup context, which can be 
easily done, and *fixing the code* which should have never been written this 
way in the first place: 

For there really is nothing “natural” about this code, in which a variable 
or property “y” is pre-decremented [--…] in an *“if”* statement (of all the 
things), the resulting value is converted to boolean [!…], and then the 
*boolean value* is compared *arithmetically* or as a *string*, depending on 
the type of “x”, against another variable or property value “x” [“<”]; 
*nobody remotely in their right mind writes ECMAScript-based code like 
this*.  (And then “player<script”?  Give me a break.)

[1] <http://PointedEars.de/es-matrix>

> No regexes, no imaginary errors, just plain string replacement. Look:
> 
>     str_replace("<script", "<\script", $some_text);
> 
> Done.

No.  (And it is bad practice to use unknown escapes in double-quoted string 
literals in PHP.  It is also unwise to use double-quoted string literals 
where single-quoted string literals would have sufficed, because different 
to ECMAScript, double quotes also imply interpolation in PHP [and several 
other script languages].)

> And even *IF* it was a Perl regex (which is a completely random
> and off-topic assumption), the "\s" is in the replacement part, not in
> the matching part.

I was talking about code that can be (but does not have to be) contained in 
markup, code that uses regular expressions to match and process markup.
That code will be broken by blind escaping to accomodate HTML parsers.

>> [...] the HTML5 Specification (fortunately) does not even define
>> syntax that would require  “</script>” in a “script” element to be
>> escaped in any way [...] The authors of this paragraph did not know
>> what the hell they were doing [...] one cannot trust the authors of
>> HTML Specifications regarding advice relevant to Web programming
>> languages [...]
> 
> It is an awkward area of the specification, I grant you that. They
> pretty much acknowledge that when they mention the "rather strange
> restrictions". They were trying to remain backward compatible with
> existing usage (up to a point), which is why we still have those
> slightly absurd edge cases with <!--, <script> etc.
> 
> But they did get it right,

In convenient edge cases only, which is the problem.

> or at least they and the current user agents agree.

Interesting.  As for Chromium 44.0.2403.89 on GNU/Linux, for which I can 
confirm that unescaped “</script>” in a “script” element is a problem, this 
should be considered a bug as (AFAICS) the given ABNF for the “script” 
element content allows “</script>” in it.

It is probably rather a Specification bug than a browser bug, given that an 
HTML parser needs a way to recognize the end of the “script” element, and 
that this way should be as simple as reasonably possible in order to avoid 
greater complexity in the parser.  But see below.

> You apparently don't, but you're the odd one out here. By all
> means, go ahead and write something like this:
> 
> <script>
>   console.log("This is just a string</script>");
>   console.log("And this is another");
> </script>
> 
> If you think that's safe, good luck to you. You're going to need it.

Straw man.  I did _not_ say that I think that it is *safe*.  I said that it 
is not a problem in those markup languages.  Which is correct (in theory).
 
> By the way, you also mentioned this wouldn't be a problem in XHTML.

I did, and it is not (if you serve XHTML properly).

> To get a valid XML document, you'll have to escape much more than the
> strings I mentioned.

No, as I have said many times before in both in 
<news:de.comp.lang.javascript> and here, you just have to declare the 
offending “script” element content a part of a CDATA section, and escape the 
CDATA section end marker.  BTDT:

  <script type="text/javascript">// <![CDATA[

     // escape “]]>” here if “<” follows

  // ]]></script>

Because the XML CDATA type/section is not so ill-defined as the SGML CDATA 
content type that its value would end when the parser encountered an ETAGO 
(End-TAG Open) delimiter.  However, this only applies to markup validation 
and to XHTML served as application/xhtml+xml.  If you serve XHTML as 
text/html instead (which is only necessary if you insist on using XHTML 
*and* want to support obsolete browsers such as IE 8), then an HTML parser 
is used, and the HTML escaping measures would have to be applied as well.

[“Validate by input” on <http://validator.w3.org/> now recognizes the HTML5 
"doctype", and uses the new <http://validator.w3.org/nu/> if you submit the 
form and have chosen “Validate Full Document”, and “(detect automatically)” 
or “HTML5 (experimental)”.]

But none of this is necessary, regardless of the document type, if you move 
the “script” element content to a separate file, and use the “src” 
attribute, AISB.  Much simpler than considering the document type, escaping 
everything based on that; and much safer – namely completely safe.  On top 
of that, it is easier to maintain, because syntax highlighting and related 
features depend less on the capabilities of the used code editor, less on 
its ability to recognize the context.

> [whining about leaving the newsgroup]

That is your problem alone.  If you can’t stand the heat (of constructive 
criticism), and are unwilling to check your assumptions and to participate 
in the mutual learning process, (only then it makes sense for you to) stay 
out of the kitchen.

IOW: Your logic is flawed.  You should learn to control your emotions lest 
they control you.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.