The Lucee docs seem to indicate that ESAPIEncode() is deprecated. Your comment is quite old, but it surfaced from a google search faster than the docs. Do the docs need to be updated or has Lucee changed its mind on the deprecation of encodeForHTML() again?
So far as I know, no other decisions have been made. Don’t read too much into the deprecations. It’s not like we’re going to remove any of the functions, it’s just a hint as to the one we recommend you use. Micha doesn’t like ot have two functions that do the same thing without having some sort of indicator of what the “recommended” one is. So read “deprecated” as “we recommend the other function that does the exact same one as this one but it’s not like this one will ever go away”.
Oh, a small historical note that I remembered after hitting send on my previous comment. The specific reason the “ESAPI” function was deprecated was because Micha originally thought “ESAPI” just meant something generic to security or something so he thought it was just a good, generic function name. When I pointed out (this was several years ago) that ESAPI was literally the name of the specific java library in use and if we ever swapped out that library, the name wouldn’t make sense is when he agreed to deprecate that one in favor of the more generically named functions. I think it went something like this:
- Adobe came out with the individual
encodeForXXX()functions - Lucee copied them and then Micha tried to ‘improve’ on them by creating a single encoding function to rule them all called
ESAPIEncode( 'XXX' ) - Micha liked his approach so he deprecated the individual function names in favor of his singular one
- I convinced him using the word “ESAPI” was vendor lock in (in name anyway) and it got made more generic into just
encodeFor( 'XXX' )at which point the ESAPI version was deprecated. - After I had to deal with a stubborn client who REFUSED to use the individual functions because they were marked as “deprecated” and they also refused to listen and understand what Lucee actually meant by that I spoke with MIcha, and quoting Uncle Bob’s “Clean Code” book, convinced Micha that specific functions with fewer params was actually better than a single generic function with more params. He agreed and reversed the deprecated notice in the docs.
- In the ensuing years to follow many developers have been confused at the wreckage of similar and paritially deprecated functions in Lucee.
hmmm… somehow I am confused, and I changed my code because of this functions a lot of times already…
At esapiEncode CFML Documentation it says it is deprecated since lucee 5. At docs.lucee.org it’s not deprecated. It says encodeforhtml is deprecated, to use esapiencode instead. And the old htmleditformat should be avoided because of XSS.
I can remember, but can’t find the post anymore (may be I read it on slack) that somebody updated Lucee to a RC and was having issues because of one of that functions, and received the answer he should use esapiencode instead. But esapiEncode(encodeFor,string) is not a ACF function, so there would be problems with portability. So now what should I do?
When I read “deprecated” I undestand that I should avoid that command/function in new projects or when updating/upgrading the software. What should I use? If encodeforhtml is OK, why not remove the “This function is deprecated, use function ESAPIEncode(‘html’,…) instead.” from EncodeForHTML() :: Lucee Documentation then?
I think this is a situation of the docs needing to be updated and no one has done it yet. I see no reason not to use the encodeFor* functions. While they may be marked as deprecated in the docs, I have heard zero implication in recent times that they would ever be removed. The chances of that happening are slim as it would inevitably break compatibility with ACF.
I personally have never used the esapiEncode() function specifically.
Looks like this could be fixed with an easy Hacktoberfest pull request for someone with 5 minutes to spare: lucee-docs/function.md at master · lucee/lucee-docs · GitHub
1 Like