Should jsstringformat do more?

I had always believed that jsstringformat did absolutely everything necessary to string of text in order to set it into a JavaScript string variable. I realized last night I was wrong.   The following HTML example will error: <script LANGUAGE="JavaScript" TYPE="text/javascript">     alert('</script>'); </script> Even though the text "</script>" is a perfectly escaped JavaScript string-the browser apparently parses the tags BEFORE the JavaScript and prematurely ends the "real" script block. I noticed this when playing with an interface which cfsavecontents a display file, and then sets its contents into a JavaScript variable so it can later be pushed as the innerHTML to a floating DIV without hitting the server. Please suppress the urge to ask "why".  It's an experiment, and yes I realize JavaScript is NOT evaluated when innerHTML'd.  We have developed some nifty JS regex to parse out all the JavaScript and eval it into existence so the framework can be agnostic in that manner. At any rate, I said that to say this: Here was my quick solution: <script LANGUAGE="JavaScript" TYPE="text/javascript"> var my_js_string = '#replacenocase(jsstringformat(cf_var_containting_html),"script","scr'+' ipt","all")#'; </script> But, should I have to do that?  If jsstringformat's job could be loosely defined as handling ALL escaping of a string to make it save for JavaScript, should it handle ending script tags as well since those obviously aren't safe? I am willing to accept the fact that escaping script tags might be out of scope (and difficult) for the jsstringformat function, but I wanted to hear your thoughts first. ~Brad

It shouldn't do that.  It formats a string, and all of those characters are valid characters within a JS string.  You wouldn't want to do anything special if you were serving a JS file out to the browser; it's only when you're serving JS embedded in an HTML file that you need to worry about </script> tags in the strings.  So it's a response assembly problem, not a string formatting problem. cheers, barneyb On Dec 31, 2007 10:55 AM, Brad Wood <bradwood@nationsholding.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

> It shouldn't do that.  It formats a string, and all of those > characters are valid characters within a JS string.  You wouldn't want > to do anything special if you were serving a JS file out to the > browser; it's only when you're serving JS embedded in an HTML file > that you need to worry about </script> tags in the strings.  So it's a > response assembly problem, not a string formatting problem. Not true. You run a ezine and you ask me to write an article. I title my article "the End of </script>" and enter it into the form. The title of articles is known to be an atomic value, so whatever I enter in that field, should show up *exactly* that way, no matter where it's output, and regardless of what I chose to put in it. I could title my article "</script></script></script></script>nnn... blah blah I'm the king of France" - it doesn't matter, because it's a literal, atomic value. If I enter "the End of </script>" and it gets butchered when it goes somewhere else, that's a bug. FURTHER SerializeJSON actually *does* format those strings properly in a way that doesn't break. CFWDDX on the other hand does not. And given that we're talking about a trivial change, it doesn't make any sense at all to push back and say "oh no, it's supposed to have that limitation." </rant> -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 503.236.3691 http://onTap.riaforge.org/blog

>>If I enter "the End of </script>" and it gets butchered when it goes somewhere else, that's a bug. If it's a bug, it is only in the CMS that did not make sure the HTML code it produces was right. Not in the HTML parser. The HTML parser does not parse the Javascript code, so obviously, the parser must rely on its end tag </script> to resume parsing HTML code. This imply that by definition the JS code cannot contain anywhere the string "</script>". -- _______________________________________ REUSE CODE! Use custom tags; See http://www.contentbox.com/claude/customtags/tagstore.cfm (Please send any spam to this address: piegeacon@internetique.com) Thanks.

> If it's a bug, it is only in the CMS that did not make sure the HTML > code it produces was right. Not in the HTML parser. The HTML parser > does not parse the Javascript code, so obviously, the parser must rely > on its end tag </script> to resume parsing HTML code. This imply that > by definition the JS code cannot contain anywhere the string > "</script>". I agree. Therefore, jsstringformat should format strings the way SerializeJSON does. -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 503.236.3691 http://onTap.riaforge.org/blog

>>Therefore, jsstringformat should format strings the way SerializeJSON does. I don't agree: The purpose of jsstringformat is to make a string safe as a Javascript string in a Javascript context, no more. JSON is a text format that is completely language independent, not only Javascript, but also HTML, big difference. The context is much wider, so the escaping must be more agreessive. -- _______________________________________ REUSE CODE! Use custom tags; See http://www.contentbox.com/claude/customtags/tagstore.cfm (Please send any spam to this address: piegeacon@internetique.com) Thanks.

----- Excess quoted text cut - see Original Post for more ----- Then the context of jsstringformat should be widened. -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 503.236.3691 http://onTap.riaforge.org/blog

>>Then the context of jsstringformat should be widened. Ok, then call it JSstringInHTMLformat. ;-) -- _______________________________________ REUSE CODE! Use custom tags; See http://www.contentbox.com/claude/customtags/tagstore.cfm (Please send any spam to this address: piegeacon@internetique.com) Thanks.

If anyone really feels strongly about this, they should create a function that does what they want, name it something more useful and specific, and place it on cflib.org Then put a note on the livedocs pointing to the new function. Finally, watch and see how many people then go download the function that "fixes" JSStringFormat. If enough people do so, I can almost guarantee that the Adobe dev staff will take notice, and look at including that or a similar function in the next version of cf. This would be both useful, and possibly educational. On Jan 2, 2008 1:45 AM, Claude Schneegans <schneegans@internetique.com> wrote: >  >>Then the context of jsstringformat should be widened. > > Ok, then call it JSstringInHTMLformat. ;-)

>>If enough people do so, I can almost guarantee that the Adobe dev staff will take notice, and look at including that or a similar function in the next version of cf. Based on experience with dealing with empty list elements in list functions, it may take a long time ;-) -- _______________________________________ REUSE CODE! Use custom tags; See http://www.contentbox.com/claude/customtags/tagstore.cfm (Please send any spam to this address: piegeacon@internetique.com) Thanks.

_New_ function, not a change (potentially breaking existing applications). On Jan 2, 2008 3:05 AM, Claude Schneegans <schneegans@internetique.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

> _New_ function, not a change (potentially breaking existing > applications). nope... won't break any existing applications... Honestly, I think I'm going to stop recommending people use jsstringformat in general and recommend they use SerializeJSON for string values instead... -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 503.236.3691 http://onTap.riaforge.org/blog

> If anyone really feels strongly about this, they should create a > function that does what they want, name it something more useful and > specific, and place it on cflib.org function JSF(s) { return replacelist(s,""",',/","\"",\',\/"); } The problem isn't that it can't be done -- the problem is that people (programmers) expect it to be bulletproof for a common situation which it's not... it could be... but there's some strange desire to not make it bulletproof based on a fear of ambiguous problems that might arise from fixing the specific problem that we know exists. Putting a note in the livedocs doesn't resolve the issue because the number of people that will reach will be miniscule. And even educating people that they shouldn't use jsstringformat isn't really something we should have to do. It should just be bulletproof *if* we can make it so without negative side effects, and it's been proven that we can. -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 503.236.3691 http://onTap.riaforge.org/blog

So, do you consider that to be a browser bug or is the replace method really the "right" way to do it? I mean, it seems logical why my browser acts the way it does-- but the solution sure seems kludgy... it just doesn't seem right. ~Brad It shouldn't do that.  It formats a string, and all of those characters are valid characters within a JS string.  You wouldn't want to do anything special if you were serving a JS file out to the browser; it's only when you're serving JS embedded in an HTML file that you need to worry about </script> tags in the strings.  So it's a response assembly problem, not a string formatting problem. cheers, barneyb

> I had always believed that jsstringformat did absolutely > everything necessary to string of text in order to set it > into a JavaScript string variable. JSStringFormat escapes JavaScript metacharacters; nothing more, nothing less. That's all it does, and that's all it's supposed to do. ----- Excess quoted text cut - see Original Post for more ----- What does that have to do with JSStringFormat, or CF at all for that matter? You can do that in an HTML page, without CF at all, and get the exact same result, right? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

> So, do you consider that to be a browser bug or is the > replace method really the "right" way to do it? I certainly wouldn't consider it a browser bug. The browser's job, first and foremost, is to parse HTML. The closing SCRIPT tag is HTML. The browser can't be expected to look at your closing SCRIPT tag and ask itself "is this really the closing SCRIPT tag?" Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

>> I had always believed that jsstringformat did absolutely >> everything necessary to string of text in order to set it >> into a JavaScript string variable. > JSStringFormat escapes JavaScript metacharacters; nothing more, nothing > less. That's all it does, and that's all it's supposed to do. The LiveDocs for CF7 simply state jsstringformat returns "A string that is safe to use with JavaScript.".  I think it is obvious that "</script>" is not a "safe" string under certain JavaScript conditions. Ok, so technically, "</script>" IS safe with JavaScript alone-- but it isn't a "safe" string to have in JavaScript which is embedded in an HTML document-- and most JavaScript is found in HTML documents.  I don't think there's anything particularly wrong with your exacting definition of the function-- what I'm asking here is _should_ that be the way the function works?   So it seems jsstringformat may meet the letter of the law.  Everybody pat Adobe on the back.  But isn't it a bit misleading?  Could it be better?  Should there be a second function which makes a string safe for JavaScript embedded in an HTML document? Yeah, sure-- there's the replacenocase() function, but again we don't really NEED jsstringformat either.  We could replace those meta-characters manually as well.  Obviously Adobe doesn't make a function for EVERYTHING we need, but what I am trying to do is to get people to stop and think if it would be useful to re-define this function or add another.  Discussion is what I'm looking for-- not for someone to jump down my throat and inform me its working as designed. I like ColdFusion because it takes those tricky mundane things and makes them simpler.  Htmleditformat.  Jsstringformat.  ParagraphFormat. This seems like one of those places where CF might have missed an opportunity.   > What does that have to do with JSStringFormat, or CF at all for that > matter? You can do that in an HTML page, without CF at all, and get the > exact same result, right? You are absolutely right.  That was a simplified HTML example to show the browser behavior.  Had you kept reading, you would have seen the example which involved ColdFusion. ~Brad

My feeling would be no. I like the way it currently works. JSStringFormat does what the function says. It is not called JSSafeFromAnything. As you point out, it is only unsafe under certain conditions. So I am glad it does not always strip everything out that might possibly meet a seldom seen condition. On Dec 31, 2007 4:09 PM, Brad Wood <bradwood@nationsholding.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

> As you point out, it is only unsafe under certain conditions. You mean any condition in which a user might have entered something into a form? As compared to: What circumstance in which would it be a problem if it escaped the </script> string? I can tell you what circumstance in which that would happen -- NEVER. So... sometimes a problem, vs. never a problem... Personally, I prever never. -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 503.236.3691 http://onTap.riaforge.org/blog

On Dec 31, 2007 6:26 PM, s. isaac dealey <info@turnkey.to> wrote: ----- Excess quoted text cut - see Original Post for more ----- Whether it would be NEVER or not, the simple fact is that it's IMPOSSIBLE for CF to do this.  The only way I can think to do it would be as a postprocessing of the entire generated content (an outbound servlet filter) with a full HTML and JS parser available.  Here's a relatively simple example (paste it into a text editor and remove any extra line breaks - there should be 6 lines: CFSET, A, A, carets, A, carets): <cfset myTitle = "the end of </script>" /> <a href="javascript:void(0);" onclick="return confirm('#htmlEditFormat(jsStringFormat("Are you sure you want to view #myTitle#"))#');">#htmlEditFormat(myTitle)#</a> <a href="javascript:void(0);" onclick="return confirm('#htmlEditFormat(replace(jsStringFormat("Are you sure you want to view #myTitle#"), '</script', '</scr'' + ''ipt', 'all'))#');">#htmlEditFormat(myTitle)#</a>                                                       ^              ^^    ^^ <a href="javascript:void(0);" onclick="return confirm('#htmlEditFormat(replace(jsStringFormat("Are you sure you want to view #myTitle#"), '</script', '', 'all'))#');">#htmlEditFormat(myTitle)#</a>                                                       ^         ^^ You'll notice that the five carets on line 4 all match.  What I want you to do is replace the string in line 5 denoted by the pair of carets such that you'll get the escaping you want, but you're NOT allowed to know what quote is used at the position denoted by the first caret.  It's impossible.  You have to know what that first quote is in order to be able to create the replacement string.  And there's no way to know what that first quote is (it could be ', ', or ". cheers, barneyb -- Barney Boisvert bboisvert@gmail.com http://www.barneyb.com/ Got Gmail? I have 100 invites.

Looking at what GMail did to the formatting, I've posted the raw source here: http://barneyb.com/rhino/jsstringformat.txt cheers, barneyb On Dec 31, 2007 7:26 PM, Barney Boisvert <bboisvert@gmail.com> wrote: ----- Excess quoted text cut - see Original Post for more ----- -- Barney Boisvert bboisvert@gmail.com http://www.barneyb.com/ Got Gmail? I have 100 invites.

> Whether it would be NEVER or not, the simple fact is that it's > IMPOSSIBLE for CF to do this.  The only way I can think to do it > would be as a postprocessing of the entire generated content (an > outbound servlet filter) with a full HTML and JS parser available. > Here's a relatively simple example (paste it into a text editor and > remove any extra line breaks - there should be 6 lines: CFSET, A, A, > carets, A, carets): Umm... no, far from being impossible, it'd take about 2 seconds to fix it... whatever under the hood java equivalent works well for this: replace(string,"/","\/","ALL") or if they wanted to get really fancy, rereplacenocase("<\s*/\s*(script)\s*>","<\/script>","ALL") Which I believe is precisely what SerializeJSON() does to format a string literal with the string </script> in it. I actually can't tell what you're trying to say about the script block you posted (though I did go look at the .txt file) ... -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 503.236.3691 http://onTap.riaforge.org/blog

> The LiveDocs for CF7 simply state jsstringformat returns "A string > that is safe to use with JavaScript.".  I think it is obvious that > "</script>" is not a "safe" string under certain JavaScript > conditions. Viola. It doesn't do what its documentation describes. Who here wants to call it a documentation bug? -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 503.236.3691 http://onTap.riaforge.org/blog

>>I think it is obvious that "</script>" is not a "safe" string under certain JavaScript conditions. The problem is not with Javascript here, it is with the HTML parser. The HTML parser considers that the JS code is only alert(' and passes it to the JS engine. The engine does what it can with what it gets. I think one must remember that there are two layers involved: the first layer HTML defines the <script>...</script> as containing anything except the string "</script>". -- _______________________________________ REUSE CODE! Use custom tags; See http://www.contentbox.com/claude/customtags/tagstore.cfm (Please send any spam to this address: piegeacon@internetique.com) Thanks.

----- Excess quoted text cut - see Original Post for more ----- Yes, that's how the function should work. The behavior you want is an edge case, and it's something you can easily do yourself with a workaround. However, making that the default behavior would require that CF know all of the things that could cause a JavaScript literal string to cause problems in every browser, including presumably those browsers which don't yet exist. > You are absolutely right.  That was a simplified HTML example > to show the browser behavior.  Had you kept reading, you > would have seen the example which involved ColdFusion. The second example is irrelevant. If you have the same problem with a JavaScript literal string in a static HTML page, the fact that you can generate such a string - which, as you note, is in fact a valid JavaScript literal string - with CF doesn't make this a CF problem. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

> Yes, that's how the function should work. The behavior you want is an > edge case, and it's something you can easily do yourself with a > workaround. However, making that the default behavior would require > that CF know all of the things that could cause a JavaScript literal > string to cause problems in every browser, including presumably those > browsers which don't yet exist. In spite of the fact that SerializeJSON() handles it correctly. -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 503.236.3691 http://onTap.riaforge.org/blog

> The second example is irrelevant. If you have the same problem with a > JavaScript literal string in a static HTML page, the fact that you can > generate such a string - which, as you note, is in fact a valid JavaScript > literal string - with CF doesn't make this a CF problem. I would have to disagree.  I am not attempting to blame ColdFusion for the behavior of my browser.  I am charging the documentation and behavior of the jsstringformat function to be misleading (and possibly too narrow) given the fact that it advertises "safe" strings.  I figure the majority of JavaScript is found imbedded in HTML documents.  Or at least the majority of JavaScript which would require the use of the jsstringformat function is found imbedded in HTML documents.  Based on that, I would not have considered this an "edge case".  However from the lack of "oh- I've ran into, and this is how I fixed it" responses perhaps it is more "edge" than I thought. I would probably be satisfied if the docs at least had a disclaimer that a string may need additional escaping if included in an HTML document depending on browser behavior. I must admit, although I have posed the question, I am leaning away from the idea that the default behavior of jsstringformat being different if for no other reason than it could no longer be abstracted from its use. However, I do think it is unfair of you to decry a default behavior which would require CF to know the behavior of every browser.  CF has many tags which output HTML and or JavaScript and by doing so bind their success to browser behaviors.  20 years from now when we are on HTML 8.0 all the CFFORM tags may no longer work, but that hasn't stopped us yet. ~Brad

----- Excess quoted text cut - see Original Post for more ----- That alone doesn't mean that it won't work properly. Stick this in any HTML document: <a href="javascript:window.alert('</script>');">show closing script tag</a> <a href="#" onmouseover="window.alert('</script>');">test me again</a>    You'll notice that it works just fine, in IE7 and Firefox 2.x at least. This has nothing to do with the "safety" of JavaScript string literals at all, and everything to do with HTML. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit