Description
🚀 feature request
Relevant Package
@angular/core
this line and file are of key interest:
Description
The ability to trust a custom whitelist of HTML tags, attributes, and values with a DOM sanitizer, without bypassing the whole sanitizer.
This would allow preservation of id
, style
, data attributes, and other common attributes. These attributes are useful in a variety of use cases for many Angular developers. This issue is a common cause of many GitHub issues, StackOverflow questions, and other indicators that there is a real problem with demand for a secure and flexible solution.
Related SO 1
Related SO 2
Tutorial on a best practice approach to doing what I am requesting
this would close a bunch of github issues and resolve many SO questions.
Describe the solution you'd like
I would like to be able to specify three things to allow keys and values to be sanitized in a SecurityContext.HTML.
This could be implemented as an options argument to DomSanitizer.sanitize, or it could be implemented as a custom SecurityContext, but I will use options object in my description below:
trustedFirstParagraph$ = this.translateService
.translate('some-translation-key')
.pipe(map(s => this.domSanitizer.sanitize(SecurityContext.HTML, s, options)));
Here, options can be an object with any of three keys:
const options = {
trustAttributeKeyExpression: /some-regex-to-trust/,
trustAttributeValueExpression: /some-value-to-trust/,
trustAttribute: (el, key, value): boolean | string[] => {
// arbitrary logic that can return a boolean
// or [string, string] sanitized/transformed [key, value].
}
}
trustAttributeKeyExpression
and trustAttributeValueExpression
must both match if both are specified. To implement an OR operation, and other more complex algorithms, a developer can use trustAttribute
.
Describe alternatives you've considered
- hiding data inside the class attribute and parsing it
- using a span or div inside my element which is visually hidden but which I can access through my component dom ref and parse out the value
- de-DRYing my code and having component-specific content across n components instead of being able to leverage a generic service