<cfscript> strEncodeForURL = EncodeForURL("%"); dump(strEncodeForURL); // string: "%25" dump(ESAPIDecode("url", strEncodeForURL)); // Error: SecurityConfiguration for IntrusionDetector.Disable not found // in ESAPI.properties on line 4 // Static %25 and % by itself also throw the same error: dump(ESAPIDecode("url", "%25")); dump(ESAPIDecode("url", "%")); </cfscript>
To me it looks like ESAPIEncode is deprecated
Both are according to cfdocs since v5. The answer seems to be: do not rely on them.
This really has nothing to do with the original question. The function is fine to use, it’s only “deprecated” int he sense tha tthe
encodeForXXX() functions to the same thing and the lead developer of Lucee thinks any time two functions do the same thing, one should be “deprecated” even if it will never be removed.
I think the original error is a bug in Lucee (I’ve hit it before) but it seems the only ticket that exists for it was closed as could not reproduce.
That seems like a “peculiar” reason to tag a function as “deprecated”.
It might be more efficient / (memory / cycles / etc) to use YYY instead of THIS function.
But that smells like a Documentation / language knowledge issue.
I am not sure what case I am arguing here… if I see the deprecated flag, I look for an alternative.
(Great if the documentation points me to the replacement!)
Which is the “end” result of marking it deprecated - because YYY is a better choice.
I don’t know why - but it bothers me that the use-case you mention is: “XXX is deprecated, because YYY is better.”
Perhaps I am just used to thinking (and possibly wrongly) that deprecated was all about;
“We’re no longer supporting THIS. THIS “might” go away in a future release if we have some time to kill it off, entirely.”
Your confusion regarding Lucee’s use of deprecation notices is not unique. In fact, it’s confused nearly every person who’s heard of it as best I can tell. Micha came up with the rationale for it, and it’s more based on his view that the language shouldn’t have two functions that do the same thing. So any time there are two ways to do the same thing, he chooses one to deprecate. Some times that choice is rather arbitrary… for instance, in this case the exact same internal code powers both functions, it’s just two different function names.
Funny story, it was originally the encodeForXxx() functions that were deprecated since Micha personally prefered the esapiEncode( “xxx”, … ) versions, but I was so annoyed because I had a client who REFUSED to use the deprecated version (due to the fact they were deprecated) that I convinced Micha to swap the deprecation notices in Lucee 5 because I preferred the other syntax
The OP said
ESAPIDecode() is not in the list of deprecated functions, nor does the Lucee doc page for it indicate that it’s deprecated, and the doc page for
DecodeFromURL() says “this function is deprecated, use function ESAPIDecode(‘url’,…) instead.”
The error is reproduceable as you can see in the gist, and maybe that’s why it was deprecated (assuming cfdocs.org is correct about that).
added a cross reference in docs
My understanding of deprecated was while it’s available, there may be future bugs or changes that remove it from the language. While I haven’t had enough coffee to find it, I am certain I read that recently.
I have enough to do without worrying about when the next release is going to start a code-fire.
Brad, It doesn’t sound like you agree with this and I think it’s absolutely absurd.
The beauty of code is being able to get the same solution with multiple approaches.
If this were true, why do we have switch?
- could use if/else
Loops with from/to or step? Loops over query or collection?
- deprecate those and stick with condition
There’s a proposal to add a param to listToArray
- split is mentioned as an alternative
In a guide for using higher order functions, reduce is used an a way that map or filter (so always use reduce?).
No. We have many tools so we can solve problems in different ways based on the task. That being said, why would we use deprecated duct tape knowing someone may remove it in the future?
Well, firstly you’ve taken it quite a bit further than Lucee does. They don’t consider cfif and cfswitch to be the ‘same thing’ and therefore he needs to depreceate one. It’s more when there are two similar BIFs that represent an earlier attempt and a later attempt at the same functionality, or a disagreement over the name so we created both versions. I DO agree with the concept of guiding people toward the recommended function, I disagree with using the word “deprecated” to do so as it contains a lot of extra baggage that prevents people from using perfectly good BIFs that aren’t going away any time soon.
When this was first discussed years ago on the list, it was said “but if we use the word ‘deprecated’ then that will confuse people since they generally take that to mean ‘getting removed’ entirely”. The opposing argument was basically (paraphrase) “there are lots of different definitions of deprecated and we’ll just have to communicate ours so people understand”.
Now, years later, I can unequivocally say use of that word to just mean “we recommend this over that but we’ll never remove either” was a bad idea because it has confused countless people who assume Lucee is using deprecated to mean the same thing nearly every other project uses it to mean. Personally I would have reserved “deprecated” ONLY for features literally going away or ones with inferior results (e.g.
htmlEditFormat() instead of
encodeForHTML() ) and I would have introduced another note in the docs for soft pushes like (we recommend the readability of
javaNew() instead of
createObject( 'java' ) - which was an actual discussion we had around 2015 )
Here is one of the (slightly heated) discussions from around 7 years ago where the use and suitability of the word deprecate was discussed (it’s a long thread)