feature(aio): compatible with Trusted Types #5
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bjarkler
force-pushed
the
aio-tt
branch
6 times, most recently
from
2312db6 to
1fc6827
Compare
bjarkler
force-pushed
the
aio-tt
branch
4 times, most recently
from
a188253 to
9604457
Compare
…lar#42875) In the past when we had issues with our RBE instance, we wanted to get CI green as soon as possible, and couldn't wait on the components repo to land their RBE instance fix. We manually fixed the RBE instance name using a CI step using `sed`. This is no longer needed if we update to the most recent state of the components repository. PR Close angular#42875
…ngular#42876) Previously we disabled automatic type-resolution for the API extractor because in non-sandbox environments this resulted in different API reports. There are cases where global types are still needed for analysis of an entry-point. To support this, we add a new property called `types` which allows for explicit type targets being specified. Note that we do not want to determine types from the `data` runfiles because API extractor itself also brings in types which should not always be part of the API report analysis. PR Close angular#42876
Error-handling in AIO happens mainly in two places: 1. For errors happening inside the app we have a custom `ErrorHandler` implementation, `ReportingErrorHandler`. `ReportingErrorHandler` passes errors to the default `ErrorHandler` (for them to be logged to the console) and also forwards them to `window.onerror()`. 2. Errors happening outside the app and errors forwarded by `ReportingErrorHandler` are handled by `window.onerror()`, which in turn reports them to Google analytics. Previously, we were making some assumptions (which turned out to be incorrect based on the info captured in Google analytics - see angular#28106): - `ReportingErrorHandler` assumed that the errors passed to its `handleError()` method would be either strings or `Error` instances. _Apparently, other values (such as `null` or `undefined`) may also be passed._ - `window.onerror()` assumed that if an `Error` instance was passed in, it would always have a stacktrace (i.e. its `stack` property would be defined). _This is not necessarily true, although it is not clear (based on the logs) whether reported errors of this type are caused by `Error` instance with no stacktrace or by non-string error objects which are incorrectly treated as `Error` instances. This commit ensures that all types of error arguments can be handled correctly, including `Error` instances with no stacktrace and other types of objects or primitives. NOTE: PR angular#42881 is related as it fixes handling `null` and `undefined` arguments in the default `ErrorHandler`. Fixes angular#28106 PR Close angular#42883
…lar#42884) Previously, if there was more content than what would horizontally fit in the main content area, it would overflow to the right and overlap with the Table of Contents (ToC). This was accidentally introduced in angular#42787. This commit fixes it by ensuring that the main content area will not overlap with ToC and the necessary space for the ToC will be reserved using `margin` (instead of `padding`, which contributes to the element's size). Fixes angular#42867 PR Close angular#42884
…a directive provider factory (angular#42886) When a directive provides a DI token using a factory function and interacting with a standalone injector from within that factory, the standalone injector should not have access to either the directive injector nor the NgModule injector; only the standalone injector should be used. This commit ensures that a standalone injector never reaches into the directive-level injection context while resolving DI tokens. Fixes angular#42651 PR Close angular#42886
improve the @usageNotes message by adding the word "is" (outcome: "Further information is available in...", compared to "Further information available in...") PR Close angular#42888
…erimental version (angular#42898) The angular-cli repo publishes experimental versioned packages in addition to standard versioned packages. Both experimental and standard verions, based on the expected new version provided are treated as valid and correct. PR Close angular#42898
…ngular#42872) Use the version value from the primary package.json file rather than checking the branch for the latest semver tag. This allows for us to explictly create changelogs from the previous version to the new version. PR Close angular#42872
migrate aio to eslint as tslint has been deprecated, the migration is restricted to the aio app and
its e2e tests and does not include the other tools, for such reason both tslint and codelyzer have not
been removed (to be done in a next PR)
some minor tweaks needed to be applied to the code so that it would adhere to the new ESLinting behaviour
most TSLint rules have been substituted with their ESLint equivalent, with some exceptions:
* [whitespace] does not have an ESLint equivalent (suggested to be handled by prettier)
* [import-spacing] does not have an ESLint equivalent (suggested to be handled by prettier)
* [ban] replaced with [no-restricted-syntax] as there is no (official/included) ESLint equivalent
some rules have minor different behaviours compared to their TSLint counterparts:
* @typescript-eslint/naming-convention:
- typescript-eslint does not enforce uppercase for const only.
* @typescript-eslint/no-unused-expressions:
- The TSLint optional config "allow-new" is the default ESLint behavior and will no longer be ignored.
* arrow-body-style:
- ESLint will throw an error if the function body is multiline yet has a one-line return on it.
* eqeqeq:
- Option "smart" allows for comparing two literal values, evaluating the value of typeof and null comparisons.
* no-console:
- Custom console methods, if they exist, will no longer be allowed.
* no-invalid-this:
- Functions in methods will no longer be ignored.
* no-underscore-dangle:
- Leading and trailing underscores (_) on identifiers will now be ignored.
* prefer-arrow/prefer-arrow-functions:
- ESLint does not support allowing standalone function declarations.
- ESLint does not support allowing named functions defined with the function keyword.
* space-before-function-paren:
- Option "constructor" is not supported by ESLint.
- Option "method" is not supported by ESLint.
additional notes:
* the current typescript version used by the aio app is 4.3.5, which is not supported by typescript-eslint (the supported
versions are >=3.3.1 and <4.3.0). this causes a warning message to appear during linting, this issue should
likely/hopefully disappear in the future as typescript-eslint catches up
* The new "no-console" rule is not completely equivalent to what we had prior the migration, this is because TSLint's "no-console"
rule let you specify the methods you did not want to allow, whilst ESLint's "no-console" lets you specify the methods that you do
want to allow, so and in order not to have a very long list of methods in the ESLint rule it's been decided for the time being
to simply only allow the "log", "warn" and "error" methods
* 4 dependencies have been added as they have been considered necessary (see: angular#42820 (comment))
extra:
* the migration has been performed by following: https://github.com/angular-eslint/angular-eslint#migrating-an-angular-cli-project-from-codelyzer-and-tslin
* more on typescript-eslint at: https://github.com/typescript-eslint/typescript-eslint
PR Close angular#42820
…ardRef` (angular#42887) The static interpreter assumed that a foreign function expression would have to be imported from the absolute module specifier that was used for the foreign function itself. This assumption does not hold for the `forwardRef` foreign function resolver, as that extracts the resolved expression from the function's argument, which is not behind the absolute module import of the `forwardRef` function. The prior behavior has worked for the typical usage of `forwardRef`, when it is contained within the same source file as where the static evaluation started. In that case, the resulting reference would incorrectly have an absolute module guess of `@angular/core`, but the local identifier emit strategy was capable of emitting the reference without generating an import using the absolute module guess. In the scenario where the static interpreter would first have to follow a reference to a different source that contained the `forwardRef` would the compilation fail. In that case, there is no local identifier available such that the absolute module emitter would try to locate the imported symbol from `@angular/core`. which fails as the symbol is not exported from there. This commit fixes the issue by checking whether a foreign expression occurs in the same source file as the call expression. If it does, then the absolute module specifier that was used to resolve the call expression is ignored. Fixes angular#42865 PR Close angular#42887
…42889) Previously, names of CLI commands that also happened to be keywords were shown in black color in the code block demonstrating the command's usage. This worked fine when in light mode (where the code block background is white) but not in the recently introduced dark mode (where the code block background is dark gray). This commit fixes this by ensuring the `.kwd` token color is inherited from its parent (which has an appropriate color for the current theme). Previously, the `.kwd` token was reset to its initial value (which is `black` regardless of the theme). **Before:** ![CLI pages keyword before][1] **After:** ![cli-pages-keyword after][2] [1]: https://user-images.githubusercontent.com/8604205/126073803-af317f0c-d04f-4c3a-9a83-e92541d7dd5a.png [2]: https://user-images.githubusercontent.com/8604205/126073806-1d57e3ed-90b1-4735-ae2a-d0a39862bb95.png PR Close angular#42889
…naming of child-process utils (angular#42911) Create a `spawnSync` command for common usage, additionally update naming to use `spawn` instead of `spawnWithDebugOutput` PR Close angular#42911
…#42911) Remove usages of shelljs and instead use spawn/spawnSync. PR Close angular#42911
…#42895) PullApprove deprecated the `pullapprove_conditions` config option and introduced the `overrides` option. This commit migrates to the new option, while also eliminating the `fallback` group with a simple override (as per recommendation from the pull approve docs). PR Close angular#42895
…ndleError()` (angular#42881) Since `ErrorHandler#handleError()` expects an argument of type `any` it should be able to handle values such as `null` and `undefined`. Previously, it failed to handle these values, because it was trying to access properties on them. This commit fixes it by ensuring no properties are accessed on `null` or `undefined` values. NOTE: This is part of fully addressing angular#28106. Fixes angular#21252 PR Close angular#42881
angular#42565) If the validator is bound to be `null` then no validation occurs and attribute is not added to DOM. For every validator type different PR will be raised as discussed in angular#42378. Closes angular#42267. PR Close angular#42565
…hout Angular behavior (angular#42562) In an incremental rebuild, the compiler attempts to reuse as much analysis data from a prior compilation as possible to avoid doing the analysis work again. For source files without Angular behavior however, no analysis data would be recorded such that the source file had to be reanalyzed each rebuild, even if it has not changed. This commit avoids the analysis of such source files by registering these files as not containing any Angular behavior; allowing subsequent rebuilds to avoid the analysis work. PR Close angular#42562
…he optional chaining (angular#43321) When providing the completion for `SafePropertyRead`, the ts server will not apply the optional chaining. So no need to shift the start location of `replacementSpan` back. PR Close angular#43321
…ngular#41730) * Do not emit url pop on Location.go * Emit a `popstate` event before each `hashchange` to have the same behavior of the browser. * Track the url change in the internal history when calling `simulateHashChange` The changes to the router tests reflect the goals of the test. Generally when `Location.go` is used to trigger navigations, it is only relevant for `HashLocationStrategy` and verifying that the Router picks up changes from manual URL changes. To do this, we convert those calls to `simulateHashChange` instead. Manual URL bar changes to the path when not using the `HashLocationStrategy` would otherwise trigger a full page refresh so they aren't relevant to these test scenarios which assert correct behavior during the lifetime of the router. [Reference for no `popstate` on `pushState`/`replaceState`](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event) > Note that just calling history.pushState() or history.replaceState() won't trigger a popstate event. The popstate event will be triggered by doing a browser action such as a click on the back or forward button (or calling history.back() or history.forward() in JavaScript). [Reference for `popstate` before `hashChange`](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event#when_popstate_is_sent) > When the transition occurs, either due to the user triggering the browser's > "Back" button or otherwise, the popstate event is near the end of the process to transition to the new location ... > 12. If the value of state changed, the popstate event is sent to the document. > 13. Any persisted user state is restored, if the browser chooses to do so. > 14. If the original and new entry's shared the same document, but had different fragments in their URLs, send the hashchange event to the window. BREAKING CHANGE: The behavior of the `SpyLocation` used by the `RouterTestingModule` has changed to match the behavior of browsers. It no longer emits a 'popstate' event when `Location.go` is called. In addition, `simulateHashChange` now triggers _both_ a `hashchange` and a `popstate` event. Tests which use `location.go` and expect the changes to be picked up by the `Router` should likely change to `simulateHashChange` instead. Each test is different in what it attempts to assert so there is no single change that works for all tests. Each test using the `SpyLocation` to simulate browser URL changes should be evaluated on a case-by-case basis. fixes angular#27059 PR Close angular#41730
angular#43289) Exposes implementation from angular#38884 as a public opt-in option. From that commit: > We can’t determine whether the user actually meant the back or > the forward using the popstate event (triggered by a browser > back/forward) > so we instead need to store information on the state and compute the > distance the user is traveling withing the browser history. > So by using the History#go method, > we can bring the user back to the page where he is supposed to be after > performing the action. Resolves angular#13586 PR Close angular#43289
Updates the overall Bazel setup to their latest versions: * rules_nodejs is updated to stable 4.0.0 * rules_sass is updated to the latest version containing a fix for the `@bazel/worker` bug we had a workaround for. * dev-infra-private is updated to avoid duplicated dependencies. We should use a version that also relies on stable rules_nodejs v4. Note: We are not set on how dependencies for the `bazel/` folder of the dev-infra package are managed, but we removed `@types/` packages from the transitive dependencies, so we now need to manually include `@types/uuid` for building the benchmark driver utilties. We need to revisit this in the future. PR Close angular#43322
Checks the `.ng-dev` tool configuration in CI, compared to doing it locally when the caretaker intends to perform a merge and then realizes the config is broken. PR Close angular#43322
…r#43373) Windows disallows removal of files which are currently being used. i.e. have active handles. This currently can result in permission denied failures on the Windows CI jobs where `yarn bazel` resolves to the local bazelisk installation that can be unlinked by `yarn_install` repository fetching as part of the Bazel invocation, resulting in errors like: ``` ERROR: An error occurred during the fetch of repository 'npm': yarn_install failed: $ node tools/yarn/check-yarn.js ... [4/5] Linking dependencies... info If you think this is a bug, please open a bug report with the information provided in "C:\\users\\circleci\\ng\\yarn-error.log". info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command. (warning " > [email protected]" has incorrect peer dependency "typescript@~3.3.1". error An unexpected error occurred: "EPERM: operation not permitted, unlink 'C:\\users\\circleci\\ng\\node_modules\\@bazel\\bazel-win32_x64\\bazel-0.27.0-windows-x86_64.exe'". Process stalled Active handles: - Socket - Socket - Socket ) ``` We workarund this in order to improve CI stability in case the node modules are being invalidated by Bazel, or through Yarns integrity checking. PR Close angular#43373
refering -> referring PR Close angular#43362
This corrects four typos in the HttpClient JSDoc capabilites => capabilities reuested => requested wuth => with responmse => response PR Close angular#43352
fix the "behavio" typo in the schemarics/migrations/router-link-empty-expression README file PR Close angular#43351
…ar#43323) Update the dropdown list to include core in the list of packages. PR Close angular#43323
This package is no longer needed. PR Close angular#43345
…r#43378) The TODO comment suggesting to verify that the target element to scroll to needs to be an anchor does not longer seems under consideration so it can be removed resolves angular#43348 PR Close angular#43378
With this change we change the logic to locate the tsconfig files. The public API to locate, read and parse the workspace configuration should be use instead of the custom implemented logic. The custom implemented logic depended on methods which have long been deprecated and are not removed in version 13 of the Angular CLI. This was not caught during development/UT because this repo is using outdated Angular Tooling packages. This change also updates a number of spec files which previously creating an invalid Angular workspace configuration file. Closes angular#43334 PR Close angular#43343
The Google Analytics snippet loads its runtime by dynamically creating a script element and assigning a URL to its src attribute. This causes a Trusted Types violation. To fix this, create an inline Trusted Types policy called 'aio#analytics' to bless the script URL, which is a trusted constant.
Also introduce a dependency on the Trusted Types type definitions and a Trusted Types polyfill, safevalues. Create a security module for common, security-reviewed transformations into Trusted Types.
Change the PrettyPrinter interface to accept a TrustedHTML and patch prettify.js so that it makes use of that value without modification. Update all users of the service to produce, and pass in a TrustedHTML.
Change SvgIconInfo.svgSource to be a TrustedHTML and update all its users accordingly. Also introduce the svg template tag function for building TrustedHTML from constant SVG sources.
bjarkler
force-pushed
the
aio-tt
branch
2 times, most recently
from
48bb137 to
da48fd4
Compare
Change DocumentContents.contents to a TrustedHTML and update users accordingly.
Fix a Trusted Types violation in ServiceWorkerModule that occurs when initializing the service worker from a string URL, by passing a TrustedScriptURL instead.
Configure angular.json to serve a CSP header that enabled Trusted Types in enforcement mode, both in e2e tests and when running the local development server. This should help prevent regressions related to Trusted Types in the angular.io app.
Configure Firebase to serve a CSP header on angular.io that enables Trusted Types in report-only mode. This causes any Trusted Types violations that may occur as users browser angular.io to generate a CSP report that is sent to csp.withgoogle.com, where it is processed by Google's CSP report collector. This is a non-breaking change that allows us to evaluate whether angular.io is fully compatible with Trusted Types, at which point we can start enforcing Trusted Types.
tsec is a TypeScript compiler wrapper for restricting use of security-sensitive DOM APIs, in particular those that could lead to XSS or Trusted Types violations. Add it as a linter to aio to prevent future Trusted Types regressions on angular.io. Also introduces security_exemptions.json, which lists the known, security-reviewed tsec security violations. New entries can only be added to this file after a security review, in particular making sure that the corresponding code does not cause XSS vulnerabilities or Trusted Types violations.
Increase the aio size tracking limit as a result of Trusted Types refactoring.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information