tracker issue : CF-3329177

select a category, or use search below
(searches all categories and all time range)
Title:

Deprecate obsolete and potentially dangerous encoding functionality

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 09/11/2012

Components: Documentation

Versions: 10.0

Failure Type: Unspecified

Found In Build/Fixed In Build: Final /

Priority/Frequency: Trivial / Some users will encounter

Locale/System: English / Win All

Vote Count: 2

From http://stackoverflow.com/questions/10604987/should-encodeforhtml-encodeforurl-be-used-from-cf10-onward-in-flavor-of-h/10612662#10612662

{quote}
In an earlier question encodeForHtml() vs htmlEditFormat(), how are they different, it seems like the new encodeForHtml() & encodeForURL() functions are superior than htmlEditFormat() & urlFormat() respectively.

Should the esapi-based encodeForXXX functions be used in flavor of the exiting ones? Would the 2 older functions be deprecated?
{quote}

The new functions cover all the territory the old functions did, plus they are more "aware" of more recent potential risks in incompletely escaped mark-up. I see no reason to use the old functions given the existence of the new functions.

As for deprecation, I'm all for it. If encodeForHtml() - for example - is better / more secure that htmlEditFormat(), then it is at best poor form to not flag the latter as obsolete and that the new function should be used instead. At worst it's negligent not to do so.

I would urge Adobe to mark htmlEditFormat() etc as deprecated in the docs, and advise why. I would not suggest they take it any further than deprecation at this point though.

-- 
Adam

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3329177

Deployment Phase:	Release Candidate

External Customer Info:
External Company:  
External Customer Name: Adam Cameron.
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

Comments:

I think we should refer users to use the newly introduced method as suggested here and update the docs. (Comment added from ex-user id:hkhandel)
Comment by Adobe D.
18095 | September 11, 2012 10:24:55 PM GMT
Hi Hemant and Adam, I agree something at least needs done to inform users. Could the new wording be placed into the "Usage" section of each doc, and be consistent w/ wording that is already used in other docs? For example, here is the wording in the Usage section of the ToBinary doc: "Adobe recommends that you use the BinaryDecode function to convert Base64 encoded data to binary data in all new applications." Thus, suggestions: HTMLEditFormat doc: "Adobe recommends that you use the EncodeForHTML function, not the HTMLEditFormat function, to escape special characters in a string for use in HTML in all new applications." URLEncodedFormat doc: "Adobe recommends that you use the EncodeForURL function, not the URLEncodedFormat function, to escape special characters in a string for use in a URL in all new applications." XMLFormat doc: "Adobe recommends that you use the EncodeForXML function, not the XmlFormat function, to escape special characters in a string for use in XML in all new applications." Just an idea. Thanks!, -Aaron
Comment by External U.
18096 | September 15, 2012 10:16:55 PM GMT
+1, I agree that users should be informed. Then, in a future release, deprecation should be fine. A general deprecation policy, for old functionality, should probably be discussed and planned at some point.
Vote by External U.
18099 | September 15, 2012 10:25:15 PM GMT
Assigning to Prabhuram.
Comment by Suhas Y.
18097 | October 09, 2012 02:02:02 AM GMT
+1, fully agree on deprecating.
Vote by External U.
18100 | December 28, 2012 03:44:42 PM GMT
Added the required recommendations on top of all the obsolete pages. For instance: https://learn.adobe.com/wiki/display/coldfusionen/XmlFormat
Comment by Frank J.
18098 | February 02, 2014 11:56:36 PM GMT