disableWarnings in vis timeline

[InbarTakdim]

how can i remove the following warning?
"You disabled XSS protection for vis-Timeline. I sure hope you know what you're doing!"

or in what way i can use my own component in :

visibleFrameTemplate: (item: any): any => {
const component = this.viewContainerRef.createComponent(MyComponent);
return component.location.nativeElement as HTMLElement;
},

without disable xss?

[qgustavor]

That's because this CVE. Package maintainers preferred to add a anti-XSS library and scare library users with this message. I just edited the library removing it.

I'm commenting here so I hope package maintainers remove this warning and, instead, make the documentation clear that HTML is not supported by default, a safe-subset of HTML which is unless you disable this anti-XSS thing. If you already use something that handles anti-XSS (like a templating library) this anti-XSS is redundant. In fact, I preferred if this library was skipped without this anti-XSS package at all to reduce the bundle size (at least a version without it).

The thing is, to be fair, I guess that's a result of the trend of passing raw HTML strings to libraries, which seems to be something from the jQuery era that this library still followed somehow. One current trend is working with DOM elements instead, as it makes XSS attacks way harder (as it avoids issues caused by string concatenation). An example of that is that the Mithril website used to say jQuery was not safe providing this example, except that it was not a XSS issue on jQuery, it was a misuse of jQuery by creating elements using string concatenation, and that could be easily fixed if they replaced container.append("<input value=\"" + items[i].name + "\" />"); with container.append($("<input>").attr("value", items[i].name));, which is safer and easier to read. Other option which I have seem sometimes like here, is just warning users to that the library doesn't include a HTML sanitizer and users need to choose their own.

So, not only I'm commenting here in the hope some contributor removes this warning, I'm also commenting so I hope someone thinks on a new way to library users to pass content to the library in a safe way which a string surely is not. Maybe change the API from content: "string with HTML" to content: "string with text to be passed to .innerText and template: () => /* function that returns a DOM element */.