返回哪些Access-Control- *标头以响应CORS预检OPTIONS请求，然后响应随后的GET/POST/etc.要求? [英] What Access-Control-* headers to send back in response to CORS preflight OPTIONS request and then subsequent GET/POST/etc. request?

问题描述

我正在API Gateway上建立自定义授权工作流程，并在CORS上寻找见解.

I'm setting up a custom authorization workflow on API Gateway and looking for insights on CORS.

我有一个授权者，它基于对barertoken的验证来返回IAM角色-然后调用我的目标端点的lambda，该lambda将根据需要返回响应.

I have an authorizer that returns an IAM role based on validation of a barertoken - that then invokes the lambda my target endpoint which returns the response as desired.

我通过将Barer令牌添加到OPTIONS方法和GET/POST方法中来完成这项工作.

I've made this work by adding my barer token to both the OPTIONS method and the GET/POST methods.

通常，我会将大多数CORS标头添加到OPTIONS + GET/POST/etc方法中，但这似乎是多余的.

In general, I'm adding most CORS headers to the OPTIONS + GET/POST/etc methods, but this seems superfluous.

在这里，我有点超出我的深度了，但是直觉上来说-如果需要在我的OPTIONS方法和目标方法中添加完全相同的标头，我认为AWS会简单地将标头从目标方法聚合到preflight options config，所以我假设我是在不必要的地方添加标头，但我不确定.

I'm a little outside of my depth here, but intuitively - if I needed to add the exact same headers in my OPTIONS method and the target method I think AWS would simply aggregate the headers from the target methods into the preflight options config, so I assume I'm adding the headers unnecessarily somewhere, but I'm not sure.

有人可以概述一下API网关在CORS api调用中如何传递标头吗?

Could someone please provide an overview / walk-through of how headers are being passed by API Gateway on a CORS api call?

示例信息:

endpoint: api.example.com/logout
methods: OPTIONS, GET

目前，我有: OPTIONS/GET:

request headers:
 > barerToken
response headers: 
 > set-Cookie: integration.response.body.payload.httpCookie
 > Access-Control-Allow-Headers: 'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,barerToken'
 > Access-Control-Allow-Origin: 'https://example.com'
 > Access-Control-Allow-Credentials: 'true'
 > set-cookie: integration.response.body.payload.cookie
 > Access-Control-Allow-Methods: 'OPTIONS,POST'

我的直觉表明我只需要以下内容:
OPTIONS:

My intuition says I should only need the following:
OPTIONS:

request headers:
 > barerToken
response headers:
 > Access-Control-Allow-Headers: 'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,barerToken'
 > Access-Control-Allow-Origin: 'https://example.com'
 > Access-Control-Allow-Credentials: 'true'
 > Access-Control-Allow-Methods: 'OPTIONS,POST'

GET:

response headers: 
 > set-Cookie: integration.response.body.payload.httpCookie
 > set-cookie: integration.response.body.payload.cookie

我的理解是，流程如下:
Browser (Preflight) -> End Point (OPTIONS) -> Browser (Request) -> Authorizer Lambda -> End Point (GET) -> Browser (Response)

My understanding is that the flow is as follows:
Browser (Preflight) -> End Point (OPTIONS) -> Browser (Request) -> Authorizer Lambda -> End Point (GET) -> Browser (Response)

OR

Browser (Preflight) -> Authorizer Lambda -> End Point (OPTIONS) -> Browser (Request) -> End Point (GET) -> Browser (Response)

但是我很容易误会.

最后，我应该只将授权者应用于OPTIONS方法还是应该应用于OPTIONS和GET方法?一个人与两个人相比的优点/缺点是什么?

Lastly, should I only apply the authorizer to the OPTIONS method or should it be applied to the OPTIONS and GET methods? What are the advantages/disadvantages of one versus both?

推荐答案

我将大多数CORS标头添加到OPTIONS + GET/POST/etc方法中，但这似乎是多余的.

I'm adding most CORS headers to the OPTIONS + GET/POST/etc methods, but this seems superfluous.

Access-Control-Allow-Origin响应头永远不会多余.无论请求的HTTP方法如何，它都必须包含在所有响应中.

The Access-Control-Allow-Origin response header is never superfluous. It must be included in all responses, regardless of the HTTP method of the request.

Access-Control-Allow-Methods和Access-Control-Allow-Headers标头仅在CORS预检期间由浏览器查询.有关说明相关要求的特定规范部分，请参见 https://fetch.spec .whatwg.org/#cors-preflight-fetch .因此，您必须将这些内容包括在OPTIONS响应中，但是如果需要，可以将它们从对其他HTTP方法的响应中省略.

The Access-Control-Allow-Methods and Access-Control-Allow-Headers headers are consulted by the browser only during the CORS preflight. For the specific spec section which states the relevant requirements, see https://fetch.spec.whatwg.org/#cors-preflight-fetch. So you must include those in OPTIONS responses, but you can omit them from responses to other HTTP methods if you want.

对OPTIONS请求的响应中可以省略Access-Control-Allow-Credentials响应标头，但必须将其包含在对其他方法的响应中.

The Access-Control-Allow-Credentials response header can be omitted from responses to OPTIONS requests, but it must be included in responses to other methods.

有人可以概述一下API网关在CORS api调用中如何传递标头吗?

Could someone please provide an overview / walk-through of how headers are being passed by API Gateway on a CORS api call?

1. 您的前端代码告诉浏览器它要发送带有barerToken标头的请求.
2. 您的浏览器说，好吧，带有barerToken头的请求要求我进行CORS作业前OPTIONS检查，以确保服务器允许带有barerToken头的请求.
3. 您的浏览器向服务器发送OPTIONS请求，不包含cookie，并且不包含barerToken标头(因为OPTIONS检查的整个目的是查看是否可以包含该标头)和Access-Control-Request-Headers和Access-Control-Request-Method请求标头(以告知服务器服务器必须为OK提供哪些标头和方法).
4. 您的服务器看到OPTIONS请求，并发送回200 OK响应，其中包括Access-Control-Allow-Methods和Access-Control-Allow-Headers响应标头(以指示其为OK提供哪些标头和方法)以及Access-Control-Allow-Origin标头(以指示来自请求来源的请求是否可以接受).
5. 您的浏览器会根据Access-Control-Allow-Methods，Access-Control-Allow-Headers和Access-Control-Allow-Origin响应标头中的特定值，评估预检OPTIONS响应是否成功.
6. 如果预检成功，浏览器将继续进行操作，以从您的前端JavaScript代码中发出实际的GET/POST/任何请求-包含cookie和barerToken标头.
7. 您的服务器看到请求，使用cookie和barerToken值进行所需的身份验证-然后发回您配置的任何响应，包括Access-Control-Allow-Origin(再次)和Access-Control-Allow-Credentials响应标头.

1. Your frontend code tells the browser it wants to send a request with a barerToken header.
2. Your browser says, OK, requests with a barerToken header require me to do a CORS preflight OPTIONS check to make sure the server allows requests with the barerToken header.
3. Your browser sends the server an OPTIONS request with no cookies, and no barerToken header included (because the OPTIONS check’s whole purpose is to see if it’s OK to include that header) and Access-Control-Request-Headers and Access-Control-Request-Method request headers (to tell the server what headers and method the server must give the OK for).
4. Your server sees the OPTIONS request and sends back a 200 OK response that includes the Access-Control-Allow-Methods and Access-Control-Allow-Headers response headers (to indicate what headers and methods it’s giving the OK for), and with the Access-Control-Allow-Origin header (to indicate if it is OK with requests from the origin the request came from).
5. Your browser evaluates the preflight OPTIONS response to determine whether it succeeds — based on the specific values in the Access-Control-Allow-Methods, Access-Control-Allow-Headers, and the Access-Control-Allow-Origin response headers.
6. If the preflight succeeds, the browser moves on to make the actual GET/POST/whatever request from your frontend JavaScript code — with cookies and the barerToken header included.
7. Your server sees the request, uses the cookies and barerToken value to do any authentication required — and then sends back whatever response you have configured, including the Access-Control-Allow-Origin (again) and Access-Control-Allow-Credentials response headers.

这篇关于返回哪些Access-Control- *标头以响应CORS预检OPTIONS请求，然后响应随后的GET/POST/etc.要求?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！