mirror of
https://github.com/angular/angular.git
synced 2026-09-14 13:54:52 +08:00
Ward Bell
8ef5cc680d
**Unit Testing Code Does Not Compile** The compilation error is: ``` The compilation error is ./src/testing/http-client.spec.ts - Error: Module build failed (from ./node_modules/@ngtools/webpack/src/ivy/index.js): Error: /home/projects/obk3vc--run/src/testing/http-client.spec.ts is missing from the TypeScript compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property. ``` I’m not sure what to say about unit testing HTTP in a full Standalone app. Is it different? _This is the only known remaining defect in this conversion of HTTP to Standalone._ **Edited content of `http-request-data-from-server.md`** The current version of this page is confusing. In particular * It tells readers they **should always unsubscribe** from the HttpClient method calls. This is *not true* and this example doesn't even do it. I replaced this instruction with more nuanced advice and an explanation of why it is OK to not unsubscribe to HttpClient methods. * There is a "helpful" note about using the RxJS `map` operator to transform the response. This is *not "helpfulf"*. It is *confusing* because the sample doesn't use `map` anywhere. It was unnecessary here, even if it might be helpful elsewhere. I removed this note. * The "Requesting a typed response" section seemed unclear to me, particularly because the guide begins with a `get` request that already has the `Config` return type specification. My revision attempts to make this more clear. * The bold "callout" about the `observe` and `responseType` options appears out of nowhere after "Requesting a typed response". It's disconcerting at best. I moved it to the bottom of the page and linked to it from the `options` discussion at the top. I made a few other revisions that I hope improve the readability of this page. **Corrected `http-make-jsonp-request.md`** The JSONP example, handwritten in the guide page, would not have compiled. I added one that does to `heroes.service.ts` and displayed it on this page. **Corrected `http-handle-request-errors.md` This page ended with a section called "Sending data to a server" that introduces PUT, POST, and DELETE. These features have nothing to do with error handling and the verbiage here duplicates the opening paragraphs of the next topic which does: "Send data to a server". So I deleted this section from the error handling guide page. **Archived http-setup-server-communication.md** `http-setup-server-communication.md` appears to be the original long document that has since been divided over the other pages in this folder. It shouldn’t be in the reader’s flow. I did update it for Standalone. But I also removed it from left-nav and marked as archived. PR Close #51400
38 lines
2.3 KiB
Markdown
38 lines
2.3 KiB
Markdown
# HTTP client - Security: Cross-Site Request Forgery (XSRF) protection
|
|
|
|
[Cross-Site Request Forgery (XSRF or CSRF)](https://en.wikipedia.org/wiki/Cross-site_request_forgery) is an attack technique by which the attacker can trick an authenticated user into unknowingly executing actions on your website.
|
|
|
|
`HttpClient` supports a [common mechanism](https://en.wikipedia.org/wiki/Cross-site_request_forgery#Cookie-to-header_token) used to prevent XSRF attacks.
|
|
When performing HTTP requests, an interceptor reads a token from a cookie, by default `XSRF-TOKEN`, and sets it as an HTTP header, `X-XSRF-TOKEN`.
|
|
Because only code that runs on your domain could read the cookie, the backend can be certain that the HTTP request came from your client application and not an attacker.
|
|
|
|
By default, an interceptor sends this header on all mutating requests \(such as POST\)
|
|
to relative URLs, but not on GET/HEAD requests or on requests with an absolute URL.
|
|
|
|
To take advantage of this, your server needs to set a token in a JavaScript readable session cookie called `XSRF-TOKEN` on either the page load or the first GET request.
|
|
On subsequent requests the server can verify that the cookie matches the `X-XSRF-TOKEN` HTTP header, and therefore be sure that only code running on your domain could have sent the request.
|
|
The token must be unique for each user and must be verifiable by the server; this prevents the client from making up its own tokens.
|
|
Set the token to a digest of your site's authentication cookie with a salt for added security.
|
|
|
|
To prevent collisions in environments where multiple Angular apps share the same domain or subdomain, give each application a unique cookie name.
|
|
|
|
<div class="alert is-important">
|
|
|
|
*`HttpClient` supports only the client half of the XSRF protection scheme.*
|
|
Your backend service must be configured to set the cookie for your page, and to verify that the header is present on all eligible requests.
|
|
Failing to do so renders Angular's default protection ineffective.
|
|
|
|
</div>
|
|
|
|
## Configure custom cookie/header names
|
|
|
|
If your backend service uses different names for the XSRF token cookie or header, use `HttpClientXsrfModule.withOptions()` to override the defaults.
|
|
|
|
Add it to the `bootstrapApplication()` `providers` array in `main.ts` as follows:
|
|
|
|
<code-example path="http/src/main.ts" region="xsrf"></code-example>
|
|
|
|
<a id="testing-requests"></a>
|
|
|
|
@reviewed 2023-08-16
|