Hi Amit,

It's better to encode to prevent XSS. Then of course we need to decode when 
showing those values.
Actually in this case it's automatically encoded by Freemarker as explained in this old but still good reference: https://ofbiz.markmail.org/thread/e2iznsqhhxxdplxh

So we can do the same, ie using StringUtil.wrapString(), like

<input size="60" type="text" name="description_${cartLineIndex}" 
value="${StringUtil.wrapString(cartLine.getName(dispatcher))?default("")}"/><br />

This should be done everywhere it's needed in FTL files.

I have added a patch for similar "cartLine.get...()" cases at OFBIZ-12029.
Of course other cases like that can pop out anytime; eg, I'll also fix a long 
awaiting one at  OFBIZ-7343...

We could think that using Freemarker autoescaping as suggested in OFBIZ-7675 
would be better.
But escaping is not encoding. You can check by using ?html (local autoescaping ) instead of 
StringUtil.wrapString(). You get "tes&amp;&#x23;39&#x3b;t"

For widgets forms, there is a problem currently investigated with OFBIZ-12026...

HTH

Jacques

Le 26/09/2020 à 11:00, Amit Gadaley a écrit :
Hello All,

Recently working for a client I encountered a weird issue related to
special characters encodings. We have product names containing special
characters like ' (apostrophes). When we create orders for it, an encoded
value for it is stored in OrderItem.itemDescription. The same encoded value
also copied for invoice and return. When I checked the Product entity
record, the original value (name without encoding) was stored there. I
debugged the issue at code level and found that the system does encoding
(string or html) at the time of order creation.

I understand that for security reasons (and I want to know more about it),
the system does the encodings. My concerns are related to not using
encoding when we create products. And it is not good UI experience to
display encoded forms of values to screens.

I suggest we should use some methods to display encoded values properly on
screens or remove the encoding at the very first place.

Please feel free to provide any suggestions or inputs.

Reply via email to