Hi Amit, I agree with Jacques. Though I see that in shopping cart implementation when copying product name to order item name it uses string encoding vs html encoding, I think this could be fixed to use html encoding for product/item name like it's done for product/item description in the same method.
Thanks. Mridul Pathak On Mon, Sep 28, 2020 at 2:21 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > 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&#39;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. > > >
