The description said the option allows user to determine whether to escape the Apex method’s response.
And, actually, it doesn’t “escape” the respone, but “encode” or “not encode” the response.
Am I right?
When the remote action like this:
@RemoteAction WebService static string showmsg(){ return '<script>alert(\'Hello\')</script>'; }With escape:false
showMsg() is
<script>alert('Hello')</script>With escape:true
showMsg() is
<script>alert('Hello')</script>Just try difference characters, and find actually it only encode
"=>"and<=><and>=>&rt;And, it DOESN’T encode the two escape characters :
'and\
Answer
Yep. It is handling XML escape characters (& " < >), not JavaScript. But really, most non-trival applications will use escape: false and a client-side template system to do any escaping.
The default escape: true value is just a safety net to prevent XML code being dumped into the page inadvertently, for trivial applications which fail to escape their output.
Salesforce are pushing the escaping behaviour up into the transport layer by default. While it’s not the right place, it’s in the spirit of preventing unaware developers from leaving themselves vulnerable to client-side code injection (eg).
It’s completely reasonable to have XML characters in the data (eg Grand Hotels & Resorts Ltd), and very standard front-end development practise to escape those XML characters before dumping output onto the page. Just not on the transport!
Obviously the Salesforce default behaviour will cause side effects if one intends to send XML tags around, eg via Rich Long Text fields, or any crazy server-side templating happening in a controller.
Attribution
Source : Link , Question Author : Cray Kao , Answer Author : Matt and Neil