https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25279
--- Comment #26 from Tomás Cohen Arazi <[email protected]> --- (In reply to Jonathan Druart from comment #21) > (In reply to Tomás Cohen Arazi from comment #20) > > (In reply to Jonathan Druart from comment #19) > > > > > 4. We reached a point where we don't have XSS issue in our templates, > > > > > all > > > > > variables are correctly escaped. > > > > > With this adding more JS code we should continue to enforce the rule, > > > > > all > > > > > the variables must be correctly escaped. > > > > > > > > You mean data that comes from the API???? > > > > > > I did not investigate it, I don't know where it's best to escape them. > > > > We will take a look, ideally we would do something DT-side, so this doesn't > > get borked with calls to URI/HTML encoding methods all over the place. > > Keep in mind that "sometimes" we want to display raw data, but I don't think > it should be a problem: we could unescape in that case. > > "Escape them all at the source" is maybe the way to go here but you will > certainly need to loop over all the values of the objects, even when we will > display only few of them (perf consequences?) The way datatables work, we can escape HTML entities 'only for rendering', the way I did it. I also tried adding my own render on a specific column, and DT correctly uses it and not the 'global' one, so no double escaping happens. So I think it is a nice implementation. This is lazy evaluated, so no need to loop on any row/value globally. I would prefer something in datatables.js only to ease coders life, but I also think it should be on another bug report. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
