<ul> <li *ngFor="let package of packages$ | async"> <b>{{package.name}} v.{{package.version}}</b> - <i>{{package.description}}</i> </li> </ul>
The (keyup)
event binding sends every keystroke to the component's search()
method.
(keyup)
事件绑定把每次击键都发送给了组件的 search()
方法。
Sending a request for every keystroke could be expensive. It's better to wait until the user stops typing and then send a request. That's easy to implement with RxJS operators, as shown in this excerpt.
如果每次击键都发送一次请求就太昂贵了。 最好能等到用户停止输入时才发送请求。 使用 RxJS 的操作符就能轻易实现它,参见下面的代码片段:
The searchText$
is the sequence of search-box values coming from the user. It's defined as an RxJS Subject
, which means it is a multicasting Observable
that can also produce values for itself by calling next(value)
, as happens in the search()
method.
searchText$
是一个序列,包含用户输入到搜索框中的所有值。 它定义成了 RxJS 的 Subject
对象,这表示它是一个多播 Observable
,同时还可以自行调用 next(value)
来产生值。 search()
方法中就是这么做的。
Rather than forward every searchText
value directly to the injected PackageSearchService
, the code in ngOnInit()
pipes search values through three operators:
除了把每个 searchText
的值都直接转发给 PackageSearchService
之外,ngOnInit()
中的代码还通过下列三个操作符对这些搜索值进行管道处理:
debounceTime(500)
- wait for the user to stop typing (1/2 second in this case).
debounceTime(500)
- 等待,直到用户停止输入(这个例子中是停止 1/2 秒)。
distinctUntilChanged()
- wait until the search text changes.
distinctUntilChanged()
- 等待,直到搜索内容发生了变化。
switchMap()
- send the search request to the service.
switchMap()
- 把搜索请求发送给服务。
The code sets packages$
to this re-composed Observable
of search results. The template subscribes to packages$
with the AsyncPipe and displays search results as they arrive.
这些代码把 packages$
设置成了使用搜索结果组合出的 Observable
对象。 模板中使用 AsyncPipe 订阅了 packages$
,一旦搜索结果的值发回来了,就显示这些搜索结果。
A search value reaches the service only if it's a new value and the user has stopped typing.
这样,只有当用户停止了输入且搜索值和以前不一样的时候,搜索值才会传给服务。
The switchMap()
operator has three important characteristics.
这个 switchMap()
操作符有三个重要的特征:
It takes a function argument that returns an Observable
. PackageSearchService.search
returns an Observable
, as other data service methods do.
它的参数是一个返回 Observable
的函数。PackageSearchService.search
会返回 Observable
,其它数据服务也一样。
If a previous search request is still in-flight (as when the connection is poor), it cancels that request and sends a new one.
如果以前的搜索结果仍然是在途状态(这会出现在慢速网络中),它会取消那个请求,并发起这个新的搜索。
It returns service responses in their original request order, even if the server returns them out of order.
它会按照原始的请求顺序返回这些服务的响应,而不用关心服务器实际上是以乱序返回的它们。
If you think you'll reuse this debouncing logic, consider moving it to a utility function or into the PackageSearchService
itself.
如果你觉得将来会复用这些防抖逻辑, 可以把它移到单独的工具函数中,或者移到 PackageSearchService
中。
HTTP Interception is a major feature of @angular/common/http
. With interception, you declare interceptors that inspect and transform HTTP requests from your application to the server. The same interceptors may also inspect and transform the server's responses on their way back to the application. Multiple interceptors form a forward-and-backward chain of request/response handlers.
HTTP 拦截机制是 @angular/common/http
中的主要特性之一。 使用这种拦截机制,你可以声明一些拦截器,用它们监视和转换从应用发送到服务器的 HTTP 请求。 拦截器还可以用监视和转换从服务器返回到本应用的那些响应。 多个选择器会构成一个“请求/响应处理器”的双向链表。
Interceptors can perform a variety of implicit tasks, from authentication to logging, in a routine, standard way, for every HTTP request/response.
拦截器可以用一种常规的、标准的方式对每一次 HTTP 的请求/响应任务执行从认证到记日志等很多种隐式任务。
Without interception, developers would have to implement these tasks explicitly for each HttpClient
method call.
如果没有拦截机制,那么开发人员将不得不对每次 HttpClient
调用显式实现这些任务。
To implement an interceptor, declare a class that implements the intercept()
method of the HttpInterceptor
interface.
要实现拦截器,就要实现一个实现了 HttpInterceptor
接口中的 intercept()
方法的类。
Here is a do-nothing noop interceptor that simply passes the request through without touching it:
这里是一个什么也不做的空白拦截器,它只会不做任何修改的传递这个请求。
The intercept
method transforms a request into an Observable
that eventually returns the HTTP response. In this sense, each interceptor is fully capable of handling the request entirely by itself.
intercept
方法会把请求转换成一个最终返回 HTTP 响应体的 Observable
。 在这个场景中,每个拦截器都完全能自己处理这个请求。
Most interceptors inspect the request on the way in and forward the (perhaps altered) request to the handle()
method of the next
object which implements the HttpHandler
interface.
大多数拦截器拦截都会在传入时检查请求,然后把(可能被修改过的)请求转发给 next
对象的 handle()
方法,而 next
对象实现了 HttpHandler
接口。
Like intercept()
, the handle()
method transforms an HTTP request into an Observable
of HttpEvents
which ultimately include the server's response. The intercept()
method could inspect that observable and alter it before returning it to the caller.
像 intercept()
一样,handle()
方法也会把 HTTP 请求转换成 HttpEvents
组成的 Observable
,它最终包含的是来自服务器的响应。 intercept()
函数可以检查这个可观察对象,并在把它返回给调用者之前修改它。
This no-op interceptor simply calls next.handle()
with the original request and returns the observable without doing a thing.
这个无操作的拦截器,会直接使用原始的请求调用 next.handle()
,并返回它返回的可观察对象,而不做任何后续处理。
next
对象linkThe next
object represents the next interceptor in the chain of interceptors. The final next
in the chain is the HttpClient
backend handler that sends the request to the server and receives the server's response.
next
对象表示拦截器链表中的下一个拦截器。 这个链表中的最后一个 next
对象就是 HttpClient
的后端处理器(backend handler),它会把请求发给服务器,并接收服务器的响应。
Most interceptors call next.handle()
so that the request flows through to the next interceptor and, eventually, the backend handler. An interceptor could skip calling next.handle()
, short-circuit the chain, and return its own Observable
with an artificial server response.
大多数的拦截器都会调用 next.handle()
,以便这个请求流能走到下一个拦截器,并最终传给后端处理器。 拦截器也可以不调用 next.handle()
,使这个链路短路,并返回一个带有人工构造出来的服务器响应的 自己的 Observable
。
This is a common middleware pattern found in frameworks such as Express.js.
这是一种常见的中间件模式,在像 Express.js 这样的框架中也会找到它。
The NoopInterceptor
is a service managed by Angular's dependency injection (DI) system. Like other services, you must provide the interceptor class before the app can use it.
这个 NoopInterceptor
就是一个由 Angular 依赖注入 (DI)系统管理的服务。 像其它服务一样,你也必须先提供这个拦截器类,应用才能使用它。
Because interceptors are (optional) dependencies of the HttpClient
service, you must provide them in the same injector (or a parent of the injector) that provides HttpClient
. Interceptors provided after DI creates the HttpClient
are ignored.
由于拦截器是 HttpClient
服务的(可选)依赖,所以你必须在提供 HttpClient
的同一个(或其各级父注入器)注入器中提供这些拦截器。 那些在 DI 创建完 HttpClient
之后再提供的拦截器将会被忽略。
This app provides HttpClient
in the app's root injector, as a side-effect of importing the HttpClientModule
in AppModule
. You should provide interceptors in AppModule
as well.
由于在 AppModule
中导入了 HttpClientModule
,导致本应用在其根注入器中提供了 HttpClient
。所以你也同样要在 AppModule
中提供这些拦截器。
After importing the HTTP_INTERCEPTORS
injection token from @angular/common/http
, write the NoopInterceptor
provider like this:
在从 @angular/common/http
中导入了 HTTP_INTERCEPTORS
注入令牌之后,编写如下的 NoopInterceptor
提供商注册语句:
Note the multi: true
option. This required setting tells Angular that HTTP_INTERCEPTORS
is a token for a multiprovider that injects an array of values, rather than a single value.
注意 multi: true
选项。 这个必须的选项会告诉 Angular HTTP_INTERCEPTORS
是一个多重提供商的令牌,表示它会注入一个多值的数组,而不是单一的值。
You could add this provider directly to the providers array of the AppModule
. However, it's rather verbose and there's a good chance that you'll create more interceptors and provide them in the same way. You must also pay close attention to the order in which you provide these interceptors.
你也可以直接把这个提供商添加到 AppModule
中的提供商数组中,不过那样会非常啰嗦。况且,你将来还会用这种方式创建更多的拦截器并提供它们。 你还要特别注意提供这些拦截器的顺序。
Consider creating a "barrel" file that gathers all the interceptor providers into an httpInterceptorProviders
array, starting with this first one, the NoopInterceptor
.
认真考虑创建一个封装桶(barrel)文件,用于把所有拦截器都收集起来,一起提供给 httpInterceptorProviders
数组,可以先从这个 NoopInterceptor
开始。
Then import and add it to the AppModule
providers array like this:
然后导入它,并把它加到 AppModule
的 providers
数组中,就像这样:
As you create new interceptors, add them to the httpInterceptorProviders
array and you won't have to revisit the AppModule
.
当你再创建新的拦截器时,就同样把它们添加到 httpInterceptorProviders
数组中,而不用再修改 AppModule
。
There are many more interceptors in the complete sample code.
在完整版的范例代码中还有更多的拦截器。
Angular applies interceptors in the order that you provide them. If you provide interceptors A, then B, then C, requests will flow in A->B->C and responses will flow out C->B->A.
Angular 会按照你提供它们的顺序应用这些拦截器。 如果你提供拦截器的顺序是先 A,再 B,再 C,那么请求阶段的执行顺序就是 A->B->C,而响应阶段的执行顺序则是 C->B->A。
You cannot change the order or remove interceptors later. If you need to enable and disable an interceptor dynamically, you'll have to build that capability into the interceptor itself.
以后你就再也不能修改这些顺序或移除某些拦截器了。 如果你需要动态启用或禁用某个拦截器,那就要在那个拦截器中自行实现这个功能。
You may have expected the intercept()
and handle()
methods to return observables of HttpResponse<any>
as most HttpClient
methods do.
你可能会期望 intercept()
和 handle()
方法会像大多数 HttpClient
中的方法那样返回 HttpResponse<any>
的可观察对象。
Instead they return observables of HttpEvent<any>
.
然而并没有,它们返回的是 HttpEvent<any>
的可观察对象。
That's because interceptors work at a lower level than those HttpClient
methods. A single HTTP request can generate multiple events, including upload and download progress events. The HttpResponse
class itself is actually an event, whose type is HttpEventType.HttpResponseEvent
.
这是因为拦截器工作的层级比那些 HttpClient
方法更低一些。每个 HTTP 请求都可能会生成很多个事件,包括上传和下载的进度事件。 实际上,HttpResponse
类本身就是一个事件,它的类型(type
)是 HttpEventType.HttpResponseEvent
。
Many interceptors are only concerned with the outgoing request and simply return the event stream from next.handle()
without modifying it.
很多拦截器只关心发出的请求,而对 next.handle()
返回的事件流不会做任何修改。
But interceptors that examine and modify the response from next.handle()
will see all of these events. Your interceptor should return every event untouched unless it has a compelling reason to do otherwise.
但那些要检查和修改来自 next.handle()
的响应体的拦截器希望看到所有这些事件。 所以,你的拦截器应该返回你没碰过的所有事件,除非你有充分的理由不这么做。
Although interceptors are capable of mutating requests and responses, the HttpRequest
and HttpResponse
instance properties are readonly
, rendering them largely immutable.
虽然拦截器有能力改变请求和响应,但 HttpRequest
和 HttpResponse
实例的属性却是只读(readonly
)的, 因此,它们在很大意义上说是不可变对象。
They are immutable for a good reason: the app may retry a request several times before it succeeds, which means that the interceptor chain may re-process the same request multiple times. If an interceptor could modify the original request object, the re-tried operation would start from the modified request rather than the original. Immutability ensures that interceptors see the same request for each try.
有充足的理由把它们做成不可变对象:应用可能会重试发送很多次请求之后才能成功,这就意味着这个拦截器链表可能会多次重复处理同一个请求。 如果拦截器可以修改原始的请求对象,那么重试阶段的操作就会从修改过的请求开始,而不是原始请求。 而这种不可变性,可以确保这些拦截器在每次重试时看到的都是同样的原始请求。
TypeScript will prevent you from setting HttpRequest
readonly properties.
通过把 HttpRequest
的属性设置为只读的,TypeScript 可以防止你犯这种错误。
To alter the request, clone it first and modify the clone before passing it to next.handle()
. You can clone and modify the request in a single step as in this example.
要想修改该请求,就要先克隆它,并修改这个克隆体,然后再把这个克隆体传给 next.handle()
。 你可以用一步操作中完成对请求的克隆和修改,例子如下:
The clone()
method's hash argument allows you to mutate specific properties of the request while copying the others.
这个 clone()
方法的哈希型参数允许你在复制出克隆体的同时改变该请求的某些特定属性。
The readonly
assignment guard can't prevent deep updates and, in particular, it can't prevent you from modifying a property of a request body object.
readonly
这种赋值保护,无法防范深修改(修改子对象的属性),也不能防范你修改请求体对象中的属性。
If you must mutate the request body, copy it first, change the copy, clone()
the request, and set the clone's body with the new body, as in the following example.
如果你必须修改请求体,那么就要先复制它,然后修改这个复本,clone()
这个请求,然后把这个请求体的复本作为新的请求体,例子如下:
Sometimes you need to clear the request body rather than replace it. If you set the cloned request body to undefined
, Angular assumes you intend to leave the body as is. That is not what you want. If you set the cloned request body to null
, Angular knows you intend to clear the request body.
有时你需要清空请求体,而不是替换它。 如果你把克隆后的请求体设置成 undefined
,Angular 会认为你是想让这个请求体保持原样。 这显然不是你想要的。 但如果把克隆后的请求体设置成 null
,那 Angular 就知道你是想清空这个请求体了。
Apps often use an interceptor to set default headers on outgoing requests.
应用通常会使用拦截器来设置外发请求的默认请求头。
The sample app has an AuthService
that produces an authorization token. Here is its AuthInterceptor
that injects that service to get the token and adds an authorization header with that token to every outgoing request:
该范例应用具有一个 AuthService
,它会生成一个认证令牌。 在这里,AuthInterceptor
会注入该服务以获取令牌,并对每一个外发的请求添加一个带有该令牌的认证头:
The practice of cloning a request to set new headers is so common that there's a setHeaders
shortcut for it:
这种在克隆请求的同时设置新请求头的操作太常见了,因此它还有一个快捷方式 setHeaders
:
An interceptor that alters headers can be used for a number of different operations, including:
这种可以修改头的拦截器可以用于很多不同的操作,比如:
Authentication/authorization
认证 / 授权
Caching behavior; for example, If-Modified-Since
控制缓存行为。比如 If-Modified-Since
XSRF protection
XSRF 防护
Because interceptors can process the request and response together, they can do things like time and log an entire HTTP operation.
因为拦截器可以同时处理请求和响应,所以它们也可以对整个 HTTP 操作进行计时和记录日志。
Consider the following LoggingInterceptor
, which captures the time of the request, the time of the response, and logs the outcome with the elapsed time with the injected MessageService
.
考虑下面这个 LoggingInterceptor
,它捕获请求的发起时间、响应的接收时间,并使用注入的 MessageService
来发送总共花费的时间。
The RxJS tap
operator captures whether the request succeed or failed. The RxJS finalize
operator is called when the response observable either errors or completes (which it must), and reports the outcome to the MessageService
.
RxJS 的 tap
操作符会捕获请求成功了还是失败了。 RxJS 的 finalize
操作符无论在响应成功还是失败时都会调用(这是必须的),然后把结果汇报给 MessageService
。
Neither tap
nor finalize
touch the values of the observable stream returned to the caller.
在这个可观察对象的流中,无论是 tap
还是 finalize
接触过的值,都会照常发送给调用者。
Interceptors can handle requests by themselves, without forwarding to next.handle()
.
拦截器还可以自行处理这些请求,而不用转发给 next.handle()
。
For example, you might decide to cache certain requests and responses to improve performance. You can delegate caching to an interceptor without disturbing your existing data services.
比如,你可能会想缓存某些请求和响应,以便提升性能。 你可以把这种缓存操作委托给某个拦截器,而不破坏你现有的各个数据服务。
The CachingInterceptor
demonstrates this approach.
CachingInterceptor
演示了这种方式。
The isCachable()
function determines if the request is cachable. In this sample, only GET requests to the npm package search api are cachable.
isCachable()
函数用于决定该请求是否允许缓存。 在这个例子中,只有发到 npm 包搜索 API 的 GET 请求才是可以缓存的。
If the request is not cachable, the interceptor simply forwards the request to the next handler in the chain.
如果该请求是不可缓存的,该拦截器只会把该请求转发给链表中的下一个处理器。
If a cachable request is found in the cache, the interceptor returns an of()
observable with the cached response, by-passing the next
handler (and all other interceptors downstream).
如果可缓存的请求在缓存中找到了,该拦截器就会通过 of()
函数返回一个已缓存的响应体的可观察对象,然后把它传给 next
处理器(以及所有其它下游拦截器)。
If a cachable request is not in cache, the code calls sendRequest
.
如果可缓存的请求在缓存中没找到,代码就会调用 sendRequest
。
The sendRequest
function creates a request clone without headers because the npm api forbids them.
sendRequest
函数创建了一个不带请求头的请求克隆体,因为 npm API 不会接受它们。
It forwards that request to next.handle()
which ultimately calls the server and returns the server's response.
它会把这个请求转发给 next.handle()
,它最终会调用服务器,并且返回服务器的响应。
Note how sendRequest
intercepts the response on its way back to the application. It pipes the response through the tap()
operator, whose callback adds the response to the cache.
注意 sendRequest
是如何在发回给应用之前拦截这个响应的。 它会通过 tap()
操作符对响应进行管道处理,并在其回调中把响应加到缓存中。
The original response continues untouched back up through the chain of interceptors to the application caller.
然后,原始的响应会通过这些拦截器链,原封不动的回到服务器的调用者那里。
Data services, such as PackageSearchService
, are unaware that some of their HttpClient
requests actually return cached responses.
数据服务,比如 PackageSearchService
,并不知道它们收到的某些 HttpClient
请求实际上是从缓存的请求中返回来的。
The HttpClient.get()
method normally returns an observable that either emits the data or an error. Some folks describe it as a "one and done" observable.
HttpClient.get()
方法正常情况下只会返回一个可观察对象,它或者发出数据,或者发出错误。 有些人说它是“一次性完成”的可观察对象。
But an interceptor can change this to an observable that emits more than once.
但是拦截器也可以把这个修改成发出多个值的可观察对象。
A revised version of the CachingInterceptor
optionally returns an observable that immediately emits the cached response, sends the request to the NPM web API anyway, and emits again later with the updated search results.
修改后的 CachingInterceptor
版本可以返回一个立即发出缓存的响应,然后仍然把请求发送到 NPM 的 Web API,然后再把修改过的搜索结果重新发出一次。
The cache-then-refresh option is triggered by the presence of a custom x-refresh
header.
这种缓存并刷新的选项是由自定义的 x-refresh
头触发的。
A checkbox on the PackageSearchComponent
toggles a withRefresh
flag, which is one of the arguments to PackageSearchService.search()
. That search()
method creates the custom x-refresh
header and adds it to the request before calling HttpClient.get()
.
PackageSearchComponent
中的一个检查框会切换 withRefresh
标识, 它是 PackageSearchService.search()
的参数之一。 search()
方法创建了自定义的 x-refresh
头,并在调用 HttpClient.get()
前把它添加到请求里。
The revised CachingInterceptor
sets up a server request whether there's a cached value or not, using the same sendRequest()
method described above. The results$
observable will make the request when subscribed.
修改后的 CachingInterceptor
会发起一个服务器请求,而不管有没有缓存的值。 就像 前面 的 sendRequest()
方法一样进行订阅。 在订阅 results$
可观察对象时,就会发起这个请求。
If there's no cached value, the interceptor returns results$
.
如果没有缓存的值,拦截器直接返回 result$
。
If there is a cached value, the code pipes the cached response onto results$
, producing a recomposed observable that emits twice, the cached response first (and immediately), followed later by the response from the server. Subscribers see a sequence of two responses.
如果有缓存的值,这些代码就会把缓存的响应加入到 result$
的管道中,使用重组后的可观察对象进行处理,并发出两次。 先立即发出一次缓存的响应体,然后发出来自服务器的响应。 订阅者将会看到一个包含这两个响应的序列。
Sometimes applications transfer large amounts of data and those transfers can take a long time. File uploads are a typical example. Give the users a better experience by providing feedback on the progress of such transfers.
有时,应用会传输大量数据,并且这些传输可能会花费很长时间。 典型的例子是文件上传。 可以通过在传输过程中提供进度反馈,来提升用户体验。
To make a request with progress events enabled, you can create an instance of HttpRequest
with the reportProgress
option set true to enable tracking of progress events.
要想开启进度事件的响应,你可以创建一个把 reportProgress
选项设置为 true
的 HttpRequest
实例,以开启进度跟踪事件。
Every progress event triggers change detection, so only turn them on if you truly intend to report progress in the UI.
每个进度事件都会触发变更检测,所以,你应该只有当确实希望在 UI 中报告进度时才打开这个选项。
Next, pass this request object to the HttpClient.request()
method, which returns an Observable
of HttpEvents
, the same events processed by interceptors:
接下来,把这个请求对象传给 HttpClient.request()
方法,它返回一个 HttpEvents
的 Observable
,同样也可以在拦截器中处理这些事件。
The getEventMessage
method interprets each type of HttpEvent
in the event stream.
getEventMessage
方法会解释事件流中的每一个 HttpEvent
类型。
The sample app for this guide doesn't have a server that accepts uploaded files. The UploadInterceptor
in app/http-interceptors/upload-interceptor.ts
intercepts and short-circuits upload requests by returning an observable of simulated events.
这个范例应用中并没有一个用来接收上传的文件的真实的服务器。 app/http-interceptors/upload-interceptor.ts
中的 UploadInterceptor
会拦截并短路掉上传请求,改为返回一个带有各个模拟事件的可观察对象。
Cross-Site Request Forgery (XSRF) 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 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
. Since 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.
跨站请求伪造 (XSRF)是一个攻击技术,它能让攻击者假冒一个已认证的用户在你的网站上执行未知的操作。HttpClient
支持一种通用的机制来防范 XSRF 攻击。当执行 HTTP 请求时,一个拦截器会从 cookie 中读取 XSRF 令牌(默认名字为 XSRF-TOKEN
),并且把它设置为一个 HTTP 头 X-XSRF-TOKEN
,由于只有运行在你自己的域名下的代码才能读取这个 cookie,因此后端可以确认这个 HTTP 请求真的来自你的客户端应用,而不是攻击者。
By default, an interceptor sends this cookie on all mutating requests (POST, etc.) to relative URLs but not on GET/HEAD requests or on requests with an absolute URL.
默认情况下,拦截器会在所有的修改型请求中(比如 POST 等)把这个 cookie 发送给使用相对 URL 的请求。但不会在 GET/HEAD 请求中发送,也不会发送给使用绝对 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.
要获得这种优点,你的服务器需要在页面加载或首个 GET 请求中把一个名叫 XSRF-TOKEN
的令牌写入可被 JavaScript 读到的会话 cookie 中。 而在后续的请求中,服务器可以验证这个 cookie 是否与 HTTP 头 X-XSRF-TOKEN
的值一致,以确保只有运行在你自己域名下的代码才能发起这个请求。这个令牌必须对每个用户都是唯一的,并且必须能被服务器验证,因此不能由客户端自己生成令牌。把这个令牌设置为你的站点认证信息并且加了盐(salt)的摘要,以提升安全性。
In order to prevent collisions in environments where multiple Angular apps share the same domain or subdomain, give each application a unique cookie name.
为了防止多个 Angular 应用共享同一个域名或子域时出现冲突,要给每个应用分配一个唯一的 cookie 名称。
Note that 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. If not, Angular's default protection will be ineffective.
注意,HttpClient
支持的只是 XSRF 防护方案的客户端这一半。 你的后端服务必须配置为给页面设置 cookie ,并且要验证请求头,以确保全都是合法的请求。否则,Angular 默认的这种防护措施就会失效。
If your backend service uses different names for the XSRF token cookie or header, use HttpClientXsrfModule.withOptions()
to override the defaults.
如果你的后端服务中对 XSRF 令牌的 cookie 或 头使用了不一样的名字,就要使用 HttpClientXsrfModule.withConfig()
来覆盖掉默认值。
Like any external dependency, the HTTP backend needs to be mocked so your tests can simulate interaction with a remote server. The @angular/common/http/testing
library makes setting up such mocking straightforward.
如同所有的外部依赖一样,HTTP 后端也需要在良好的测试实践中被 Mock 掉。@angular/common/http
提供了一个测试库 @angular/common/http/testing
,它让你可以直截了当的进行这种 Mock 。
Angular's HTTP testing library is designed for a pattern of testing wherein the the app executes code and makes requests first.
Angular 的 HTTP 测试库是专为其中的测试模式而设计的。在这种模式下,会首先在应用中执行代码并发起请求。
Then a test expects that certain requests have or have not been made, performs assertions against those requests, and finally provide responses by "flushing" each expected request.
然后,每个测试会期待发起或未发起过某个请求,对这些请求进行断言, 最终对每个所预期的请求进行刷新(flush)来对这些请求提供响应。
At the end, tests may verify that the app has made no unexpected requests.
最终,测试可能会验证这个应用不曾发起过非预期的请求。
You can run
你可以到在线编程环境中运行
The tests described in this guide are in src/testing/http-client.spec.ts
. There are also tests of an application data service that call HttpClient
in src/app/heroes/heroes.service.spec.ts
.
本章所讲的这些测试位于 src/testing/http-client.spec.ts
中。 在 src/app/heroes/heroes.service.spec.ts
中还有一些测试,用于测试那些调用了 HttpClient
的数据服务。
To begin testing calls to HttpClient
, import the HttpClientTestingModule
and the mocking controller, HttpTestingController
, along with the other symbols your tests require.
要开始测试那些通过 HttpClient
发起的请求,就要导入 HttpClientTestingModule
模块,并把它加到你的 TestBed
设置里去,代码如下:
Then add the HttpClientTestingModule
to the TestBed
and continue with the setup of the service-under-test.
然后把 HTTPClientTestingModule
添加到 TestBed
中,并继续设置被测服务。
Now requests made in the course of your tests will hit the testing backend instead of the normal backend.
现在,在测试中发起的这些请求将会被这些测试后端(testing backend)处理,而不是标准的后端。
This setup also calls TestBed.get()
to inject the HttpClient
service and the mocking controller so they can be referenced during the tests.
这种设置还会调用 TestBed.get()
,来获取注入的 HttpClient
服务和模拟对象的控制器 HttpTestingController
,以便在测试期间引用它们。
Now you can write a test that expects a GET Request to occur and provides a mock response.
现在,你就可以编写测试,等待 GET 请求并给出模拟响应。
The last step, verifying that no requests remain outstanding, is common enough for you to move it into an afterEach()
step:
最后一步,验证没有发起过预期之外的请求,足够通用,因此你可以把它移到 afterEach()
中:
If matching by URL isn't sufficient, it's possible to implement your own matching function. For example, you could look for an outgoing request that has an authorization header:
如果仅根据 URL 匹配还不够,你还可以自行实现匹配函数。 比如,你可以验证外发的请求是否带有某个认证头:
As with the previous expectOne()
, the test will fail if 0 or 2+ requests satisfy this predicate.
和前面根据 URL 进行测试时一样,如果零或两个以上的请求匹配上了这个期待,它就会抛出异常。
If you need to respond to duplicate requests in your test, use the match()
API instead of expectOne()
. It takes the same arguments but returns an array of matching requests. Once returned, these requests are removed from future matching and you are responsible for flushing and verifying them.
如果你需要在测试中对重复的请求进行响应,可以使用 match()
API 来代替 expectOne()
,它的参数不变,但会返回一个与这些请求相匹配的数组。一旦返回,这些请求就会从将来要匹配的列表中移除,你要自己验证和刷新(flush)它。
You should test the app's defenses against HTTP requests that fail.
你还要测试应用对于 HTTP 请求失败时的防护。
Call request.flush()
with an error message, as seen in the following example.
调用 request.flush()
并传入一个错误信息,如下所示:
Alternatively, you can call request.error()
with an ErrorEvent
.
另外,你还可以使用 ErrorEvent
来调用 request.error()
.