[Jarod Tavares]

I’m currently populating a Sublist in a SS 2.0 Suitelet, and there are problems.

[js]
Code:
var results = [/* …some data… */];

results.forEach(function (el, i) {
sublist.setSublistValue({
id: ‘field1’,
line: i,
value: el.note //user content
});
});[/js]
I can only view the first 25 results. Further pages will not load. I don’t even see any signs of activity suggesting NS is even attempting to page in more results. That alone makes this unusable. If it’s broken for such a simple scenario, it’s probably a defect.

More concerning is what I discovered while playing around with the SublistType.

For serverWidget.SublistType.EDITOR and INLINEEDITOR, text content is rendered safely to text nodes (and the Sublist is not paged; too bad I don’t want an editable Sublist). However, for the LIST and STATICLIST types, the same text is instead inserted into the DOM as HTML. Thus, just by changing the type of the Sublist, the user or third-party text I’m displaying opens me up to attack. Granted, I could conditionally escape the text, but that’s more logical overhead and easy for another developer to overlook or forget. This needs to be fixed.

It’s bad enough that this is parsed by the sublist…

Code:
[js][/js]
…but I’d be far more worried about this…

Code:
[js]
Certainly, I can account for such in this one-off script, but I should not have to.[/js]
This is a cached copy. Click here to see the original post.

[chanarbon]

Hi Jarod Tavares ,

We have already filed Issue 435362 for this concern. We may subscribe to the mentioned issue and we will keep you posted for it

---

Jarod Tavares replied on 02/27/2017, 08:04 AM: I’ve been following with much anticipation. No NS employees have accidentally sent me any passwords yet. 😉

[Author]

Posts