Home of the ColdFusion Community
|
Mailing Lists
|
Home /
Groups /
ColdFusion Talk (CF-Talk)
Should jsstringformat do more?
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295734
----- Excess quoted text cut - see Original Post for more -----
Very, because nobody expects it, therefore, nobody deals with it.
Therefore in any given application that uses jsstringformat, the problem
exists.
However. The solution is tested and proven.
"Going against the common idiom" isn't a relevant complaint in this case
because a) the solution is proven to work b) the solution is proven not
to cause other problems c) the current implementation which follows the
common idiom results in the above problem, which exists in nearly 100%
of applications that use jsstringformat. Meaning, there is a) there is a
benefit to deviating from the "common idiom" b) there is no disadvantage to
that deviation and c) there is no benefit to not deviating in this case.
> > It should just be bulletproof *if* we can make it so without
> > negative side effects, and it's been proven that we can.
>
> Just because you don't know that there are negative side effects, doesn't
> mean there aren't any. The word "proof" has a stricter meaning than that.
Okay... you're a smart guy, arguably one of the smartest people working
with ColdFusion. Give me a scenario in which escaping the / character
will cause a problem in existing code.
For example, the / character is being escaped by SerializeJSON --
although I don't know tha it's being escaped everywhere, it's definitely
being escaped if it's found in a closing script tag. Show me an example
of where properly replacing an existing case of jsstringformat with
SerializeJSON on a string value would break something that's currently
working. (That is, assuming that both instances are appropriate,
analogous uses of the respective functions, i.e. quotes or not
surrounding the function if necessary, htmleditformat() around them if
they're in a tag attribute or not if they're in a CDATA segment, etc.)
Hell, I'll make a public apology. I'd offer you a cash prize, but I
can't afford one that would be large enough to create an incentive for
you.
We have as close as human beings can come to "proof" (which admittedly may
not be all that close) in this case.
> In any case, since neither you nor I have access to the CF source code, I
> suggest you file a bug report/wishlist request/whatever and move on. Maybe
> you'll get what you want in CF9.
Given that your attitude reflects the prevailing belief about it, I'd be
really surprised if the CF team would disagree with you.
--
s. isaac dealey ^ new epoch
isn't it time for a change?
ph: 503.236.3691
http://onTap.riaforge.org/blog
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295733
> 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...
I don't know why on earth you'd expect it to be "bulletproof for a common
situation", as opposed to behaving like every other *Format function. I
don't know why you'd expect it to do anything other than replace
metacharacters, since in the common parlance of most programmers I know,
that's what it means to make a string "safe" for a specific environment.
Maybe you should change your expectations.
> 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.
Yes! I'm much more afraid of ambiguous problems that might be caused by a
change, than I am by the ones I know how to easily solve. This is especially
true for changes that go against the common idiom of a language, as this
would. Maybe I'd be more interested if the current behavior was a serious
problem, but it's not. How hard is it to deal with this one case?
> It should just be bulletproof *if* we can make it so without
> negative side effects, and it's been proven that we can.
Just because you don't know that there are negative side effects, doesn't
mean there aren't any. The word "proof" has a stricter meaning than that.
In any case, since neither you nor I have access to the CF source code, I
suggest you file a bug report/wishlist request/whatever and move on. Maybe
you'll get what you want in CF9.
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!
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295732
> 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
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295731
> _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
Author: Jerry Johnson
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295703
_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 -----
Author: Claude Schneegans
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295696
>>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.
Author: Jerry Johnson
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295695
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.
;-)
Author: Claude Schneegans
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295694
>>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.
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295693
----- 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
Author: Claude Schneegans
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295692
>>I don't think it's a good idea for one of these functions to
"guess" that I want to remove something that isn't a metacharacter when in
fact I may not.
Exact.
Another good example is the MSHTML editor which absolutizes relative
link addresses
accordingly to the directory in which the editor is run, which can be
quite different from the real context.
If I want relative address, I don't need any one to make it absolute,
especially if it does it wrong.
--
_______________________________________
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.
Author: Claude Schneegans
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295691
>>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.
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295668
> -- It is a rather sneaky gotcha' and no one seems to care-- Everyone
> (almost) seems to be saying "yeah, so what? That's TECHINCALLY right."
Which happens to be one of my biggest peeves... Like the guys who say
that javascript is "technically correct" when you ask it to perform 10/1
or some similar division and it spits back a number with a long decimal
value. It's "technically correct!" -- forget that it's basically useless...
> This whole conversation has reminded me of programmers diligently
> defending their code by insisting "But, it's working as designed!!!".
> Meanwhile, the users are saying, "That's great, but it still doesn't
> help us solve the problem."
Yeah, what Cooper talks about in Inmates.
> Maybe I should write a udf to sanitize strings to be safe for html
> script tags. How does that sound?
That's what I did. I wrapped jsstringformat with a replace of "/" so
that they're all preceded by the \ escape character -- which is proper
escaping in javascript, so it solves the problem, always works, and
never causes any new problems. I do think it escapes more characters
than SerializeJSON does tho -- I haven't looked specifically, but for
example if there's an http url in it, it turns it into http:\/\/ which I
don't think SerializeJSON does... but that's fine since the it doesn't
hurt anything to escape those characters... I suspect there's a PHP
function that does it that way too, because I remember seeing some url's
in some javascript created by PHP that looked like that a while back.
--
s. isaac dealey ^ new epoch
isn't it time for a change?
ph: 503.236.3691
http://onTap.riaforge.org/blog
Author: Brad Wood
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295666
Thanks for the remarks Claude. I do fully understand the mechanics
behind why the error occurs. I guess you could say my beef/confusion is
that:
-- For once, CF doesn't have a pre-built way escape something and it
seems odd. (Although, it has been called an "edge case")
-- It is a rather sneaky gotcha' and no one seems to care-- Everyone
(almost) seems to be saying "yeah, so what? That's TECHINCALLY right."
As vindicating as those remarks are, they don't help anyone solve the
problem. Once again, it appears I always seem to expect too much from
ColdFusion. :)
This whole conversation has reminded me of programmers diligently
defending their code by insisting "But, it's working as designed!!!".
Meanwhile, the users are saying, "That's great, but it still doesn't
help us solve the problem."
Although mentally stimulating, I would have preferred we wasted our
energy thinking how CF could be enhanced to assist in solving this
problem elegantly-- not arguing why it is "working as designed". If
that means that jsstringformat should be left alone, and
htmlscriptformat should be built, then so be it.
Maybe I should write a udf to sanitize strings to be safe for html
script tags. How does that sound?
~Brad
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295663
----- Excess quoted text cut - see Original Post for more -----
I never recommended that it remove anything. If you put \ in front of /
in a javascript literal, the literal then contains the same / that was
in the string before, it just doesn't break if it happens to be inside a
pair of script tags and has the string </script> in it. So it would
continue to work if you used
<a onclick="alert('#jsstringformat("</script>")#');">
The same way that this would work
<script>alert('#jsstringformat("</script>")#');</script>
It's simply more sanitized than it is given the current behavior.
The comparison to having UrlEncodedFormat remove SQL commands is a
straw man argument in this case, because it's not analogous to what I've
suggested. It might have been analogous if I'd suggested that it should
replace "</script>" with "" -- which is conspicuously not what I
suggested.
I'll concede if anyone can produce an example of a case in which
escaping the string would actually cause a problem. No one in this
thread has done that still that I can tell. You're still arguing against
a simple solution to a problem with no obvious side-effects on the basis
of the fear that there might be some ambiguous problem caused by it that
you can't forsee or articulate... in spite of the fact that the solution
has been tested and proven to work. Doom saying for the sake of doom
saying. Lets stop flying places, 'cause that's not natural, God would
have given us wings if he wanted us to fly.
--
s. isaac dealey ^ new epoch
isn't it time for a change?
ph: 503.236.3691
http://onTap.riaforge.org/blog
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295661
> 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
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295660
> >>This
> has nothing to do with the "safety" of JavaScript string literals at
> all, and everything to do with HTML.
>
> Absolutely.
Totally irrelevant.
--
s. isaac dealey ^ new epoch
isn't it time for a change?
ph: 503.236.3691
http://onTap.riaforge.org/blog
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295659
> > > In spite of the fact that SerializeJSON() handles it correctly.
----- Excess quoted text cut - see Original Post for more -----
You obviously need to get out more, then.
SerializeJSON and CFWDDX allow you to take things that aren't strings at
all, like queries, structures, etc, and convert them to strings.
JSStringFormat, XMLFormat, URLEncodedFormat, HTMLCodeFormat, and
HTMLEditFormat take existing strings and remove any metacharacters from
them. They sanitize the string - make it "safe" - for the specific target
environment in which the string will be used. The specific metacharacters in
question depend on the target environment in question - JavaScript, XML,
URLs, HTML. I don't think it's a good idea for one of these functions to
"guess" that I want to remove something that isn't a metacharacter when in
fact I may not. For example, I wouldn't want URLEncodedFormat to remove SQL
commands embedded in a string, even though I don't generally want SQL
commands in URLs. It's the programmer's job to deal with those specific
cases.
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!
Author: Claude Schneegans
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295653
>>This
has nothing to do with the "safety" of JavaScript string literals at all,
and everything to do with HTML.
Absolutely.
--
_______________________________________
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.
Author: Claude Schneegans
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295652
>>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.
Author: Claude Schneegans
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295651
>>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.
Author: Brad Wood
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295636
> To completely cover the latter, if you need to emit a JS string
containing > a literal "</script>" within a HTML SCRIPT block, you
manually split it > > and you're done.
Still seems like duct tape-- but I agree that does seem to be the most
(and only?) appropriate way to handle it.
> If you think there is a bug in the docs, you should enter a comment
> to that effect.
Not a bug so much as an information deficiency. I think these gotcha's
would be worth mentioning. I went to add a comment to the CF7 docs, but
it appears someone beat me to it.
> However, I don't see how you can reasonably assume that
> jsStringFormat would do anything about context-sensitive rules.
I did pose the question, but I do believe I have come to the conclusion
that jsstringformat should not be aware of its context. That being
said, I wish the docs would officially mention it. Take xmlformat() for
example. Can't you put absolutely anything into it and not break your
XML? Shouldn't you be able to feed _anything_ into htmleditformat() and
know that the results can safely be placed into a form field's value?
Why then, should people be expected to assume jsstringformat to be any
different? It just seems like CF has a nice and tidy, bullet-proof way
of escaping strings for any possible scenario under the sun with the
glaring exceptions of this hardly documented behavior. For this I have
to resort to manually kludging up by script tags and it just doesn't
feel right.
> Worth mentioning (for your comment) is that quotes cause a similar
issue
> with jsStringFormatted embedded within HTML tag event handlers. You
need > to use htmlEditFormat (or whatever) to convert the JS to valid
> HTML, because that's the context it's used in.
Hmm, good point. I had forgotten about that. At least the answer here
should be bullet-proof as long as you do <tag
onlick="alert('#htmleditformat(jsstringformat(crazy_string))#');"> That
"feels right" to me.
Thanks for the good input Barney.
~Brad
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295634
> 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
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295633
> > In spite of the fact that SerializeJSON()
> > handles it correctly.
>
> That's a different function, designed to do a different thing. Your
> comparison is analogous to complaning that XMLFormat doesn't behave
> like CFWDDX.
That's one of the dumbest things I've ever heard in my life.
--
s. isaac dealey ^ new epoch
isn't it time for a change?
ph: 503.236.3691
http://onTap.riaforge.org/blog
Author: Barney Boisvert
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295630
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.
Author: Barney Boisvert
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295629
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.
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295627
> Umm... nope, I mentioned this a few
> years ago.
OK, two people. Still an edge case.
Dave Watts, CTO, Fig Leaf Software
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295626
> In spite of the fact that SerializeJSON()
> handles it correctly.
That's a different function, designed to do a different thing. Your comparison is
analogous to complaning that XMLFormat doesn't behave like CFWDDX.
Dave Watts, CTO, Fig Leaf
Software
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295625
> If I enter "the End of </script>" and it
> gets butchered when it goes somewhere
> else, that's a bug.
Yes. A bug in your code. It is the job of your code to ensure that values are
used and stored appropriately.
Dave Watts, CTO, Fig Leaf
Software
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295623
> 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
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295622
> 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
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295621
> 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
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295620
> 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
Author: s. isaac dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295617
> I wrote that it was an edge case because you're the first person to have
> both encountered this problem and to also have suggested that CF isn't doing
> what it should.
Umm... nope, I mentioned this a few years ago. And had mentioned it on
a number of occasions since then. The fact that nobody listens, doesn't
mean that we haven't been saying anything.
--
s. isaac dealey ^ new epoch
isn't it time for a change?
ph: 503.236.3691
http://onTap.riaforge.org/blog
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295615
----- Excess quoted text cut - see Original Post for more -----
I wrote that it was an edge case because you're the first person to have
both encountered this problem and to also have suggested that CF isn't doing
what it should.
The point of my examples wasn't to preclude anything, it was simply to
demonstrate that this has nothing to do with the safety of JavaScript
strings.
Should CF automatically do something special when it encounters the string
"</script>" within a JSStringFormat function? Even if it's not necessary?
Should it look for other edge case situations that you haven't encountered
yet? If not, why not? I wouldn't be surprised if a bunch of them exist,
since you can put JavaScript string literals almost anywhere within an HTML
page.
> -- The CF Docs appear to only be accurate based on how
> tightly you define "safe".
The point of the function is to create a JavaScript string literal. It does
that. Just like XMLFormat escapes XML metacharacters, and URLEncodedFormat
escapes URL metacharacters. Both create "safe" strings for use within
specific environments. Neither of those functions look for specific problems
that could break XML documents or URLs, either. Why would you expect this
one function to behave differently from all of the other ___Format
functions?
> -- The CF docs are for public consumption, not for a
> super-elite ring of CFer's who already have intimate
> knowledge of the language.
You don't have to be a super-elite anything, you just have to understand how
JavaScript works within a browser.
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!
Author: Barney Boisvert
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295612
To completely cover the latter, if you need to emit a JS string containing a
literal "</script>" within a HTML SCRIPT block, you manually split it and
you're done. jsStringFormat will make ensure a CF string is safe for use as
a JS string, according to the rules of the JS language. It doesn't (and
can't) do anything for context-sensitive rules (embedded in a HTML SCRIPT
block, embedded in a tag's event handler, etc). If you think there is a bug
in the docs, you should enter a comment to that effect. However, I don't
see how you can reasonably assume that jsStringFormat would do anything
about context-sensitive rules.
Worth mentioning (for your comment) is that quotes cause a similar issue
with jsStringFormatted embedded within HTML tag event handlers. You need to
use htmlEditFormat (or whatever) to convert the JS to valid HTML, because
that's the context it's used in.
cheers,
barneyb
On Dec 31, 2007 3:50 PM, Brad Wood <bradwood@nationsholding.com> wrote:
----- Excess quoted text cut - see Original Post for more -----
Author: Brad Wood
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295611
Naturally your examples do not error since you have demonstrated a
JavaScript string containing the text "</script>" which is not contained
within "real" script tags. My onus however, was not to prove that EVERY
arbitrary "</script>" embedded within a JS string in an HTML document
would error but rather the possibility of such errors were not an "edge
case". Your examples, while accurate, do not preclude the many ways JS
strings can and are contained within real script tags.
Regardless of how you want to classify the behavior, these facts still
remain:
-- The CF Docs appear to only be accurate based on how tightly you
define "safe".
-- The Docs make no official note that the jsstringformat will NOT
produce a string which can safely be output within script tags in an
HTML page.
-- It is my opinion that this caveat is not obvious enough to assume
readers will consider it.
-- The CF docs are for public consumption, not for a super-elite ring of
CFer's who already have intimate knowledge of the language.
Ahh... we have digressed far-- as usual. My original intent was not to
pick on the Docs, but to provoke open-minded discussion and elicit
examples of how other people had dealt with the topic. I'd say we've
beaten the former into the ground (as usual) but never touched the
latter.
~Brad
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295608
----- 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 http://training.figleaf.com/ for more
information!
Author: Brad Wood
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295607
> 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
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295606
----- 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!
Author: Jerry Johnson
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295605
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 -----
Author: Brad Wood
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295604
>> 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
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295603
> 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!
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295600
> 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!
Author: Brad Wood
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295599
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
Author: Barney Boisvert
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295590
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 -----
Author: Brad Wood
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54678#295589
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
|
May 24, 2012
|
Latest Fusion Authority Articles
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
