4

I'm seeing a difference in how HTMLEditFormat works in CF9 and CF10. 

HTMLEditFormat(">")
  • In CF9: showing up as ">" (no difference)
  • In CF10: showing up as ">" (double-escaped, which seems correct to me)

I've looked through the CF10 notes and reviewed the HTMLEditFormat documentation, but cannot find any mention of there being a difference in how this function works. Does anyone know of a difference, or know of documentation that proves there is no difference? ...Or know of any other settings (ColdFusion or web server) that might cause this to work different?

(This question is not a duplicate because am not asking about encodeForHTML. I understand that is the ideal solution, but am asking to understand why HTMLEditFormat might be different in CF9 vs. CF10.)

Community
  • 1
  • 1
Luke
  • 18,811
  • 16
  • 99
  • 115
  • sorry about marking it as duplicated earlier, I'd file this as a bug for CF9 at : bugbase.adobe.com but I doubt Adobe will bother fixing anything for CF9. They will just ask you to upgrade the latest CF. – Henry May 29 '14 at 21:31
  • 1
    Are you looking at the HTML source that is generated to verify the values? I tested on ColdFusion 9 and it works as documented; `< = <` and `> = >` and `& = &` and `" = "` and finally `> = &gt;`. – Miguel-F Jun 03 '14 at 12:47
  • Yes, I am. To clarify: when I say "showing up as" I mean in the source HTML, not the rendered webpage. Thanks for trying this out. The two servers I'm testing on have the same code but are not 100% the same (aside from CF versions), so there could be something else that is un-escaping the text on the server-side. I just don't know what it could be. So I guess the second question I have is the real one: "Know of any other settings (ColdFusion or web server) that might cause this to work different?" – Luke Jun 05 '14 at 19:08

1 Answers1

3

I can't imagine why that function would behave differently. Especially when it's was planned for deprecation going into CF 10. By chance, are you calling it from within a CFINPUT tag?

<cfinput id="foo" value="#htmlEditFormat(someValue)#" />

If so, in CF6 - CF9, that tag uses HTMLEditFormat() on values automatically. Calling a 2nd instance of HTMLEditFormat() doesn't affect the output. But CF 10+ updated the tag to use encodeForHTML() on values. If you also throw in an HTMLEditFormat(), then you're double-encoding the output.

For better security, you should stop using HTMLEditFormat() and start using encodeForHTML() if it's available (CF10+). As of ColdFusion 11, HTMLEditFormat() has been officially deprecated and by ColdFusion 12, the function should be removed completely.

HTMLEditFormat() only encodes 4 characters: <, >, &, ".

encodeForHTML() encodes almost every character, including UTF-8 characters. The updated "encodeFor" functions are contextual, so you have to pick the right on for the right context (html, htmlattribute, js, css, xml, etc.).

Adrian J. Moreno
  • 14,350
  • 1
  • 37
  • 44
  • I'm not using cfinput, I've just isolated the problem so all I'm doing is basically `writeOutput(HTMLEditFormat(escapedCharacters));` Unfortunately we can't take advantage of CF10's `encodeForHTML()` function, although I know that would be the best solution! – Luke May 29 '14 at 19:45
  • Just a minor point: just because HTMLEditFormat() is now deprecated doesn't mean it will be removed any time soon (like in CF12). There's a bunch of stuff that was deprecated as far back as CF6 that either is still hanging around or was just finally removed in CF11. – Carl Von Stetten May 30 '14 at 04:20
  • Yes, but the CF team has already stated that CF 12 WILL break backward compatibility by removing certain deprecated functions like HTMLEditFormat(). http://cfmlblog.adamcameron.me/2013/10/cfsummit-interesting-coldfusion-12-stuff.html – Adrian J. Moreno Jun 05 '14 at 16:07