2e4d17f3a9
In VE the `Sanitizer` is always available in `BrowserModule` because the VE retrieves it using injection. In Ivy the injection is optional and we have instructions instead of component definition arrays. The implication of this is that in Ivy the instructions can pull in the sanitizer only when they are working with a property which is known to be unsafe. Because the Injection is optional this works even if no Sanitizer is present. So in Ivy we first use the sanitizer which is pulled in by the instruction, unless one is available through the `Injector` then we use that one instead. This PR does few things: 1) It makes `Sanitizer` optional in Ivy. 2) It makes `DomSanitizer` tree shakable. 3) It aligns the semantics of Ivy `Sanitizer` with that of the Ivy sanitization rules. 4) It refactors `DomSanitizer` to use same functions as Ivy sanitization for consistency. PR Close #31934
26 lines
626 B
TypeScript
26 lines
626 B
TypeScript
/**
|
|
* @license
|
|
* Copyright Google Inc. All Rights Reserved.
|
|
*
|
|
* Use of this source code is governed by an MIT-style license that can be
|
|
* found in the LICENSE file at https://angular.io/license
|
|
*/
|
|
|
|
/**
|
|
* A SecurityContext marks a location that has dangerous security implications, e.g. a DOM property
|
|
* like `innerHTML` that could cause Cross Site Scripting (XSS) security bugs when improperly
|
|
* handled.
|
|
*
|
|
* See DomSanitizer for more details on security in Angular applications.
|
|
*
|
|
* @publicApi
|
|
*/
|
|
export enum SecurityContext {
|
|
NONE = 0,
|
|
HTML = 1,
|
|
STYLE = 2,
|
|
SCRIPT = 3,
|
|
URL = 4,
|
|
RESOURCE_URL = 5,
|
|
}
|