预检请求中的跨域Cookie

本文介绍了预检请求中的跨域Cookie的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

两个组成部分:

react.mycompany 上的React单页应用程序

apigee.proxy

上的Apigee API代理

登录时，Apigee使用 Set-Cookie 标头设置 jwt cookie:

Set-Cookie:jwt = {jwtoken}；安全； httponly； path =/； samesite = none

在客户端，Chrome浏览器向我显示了 react.mycompany 框架的cookie:

名称:jwt值:XXX域:apigee.proxy小路:/httpOnly:正确安全:正确sameSite:无

现在，在非身份验证请求上，Apigee在处理请求之前会检查 jwt cookie的存在.

未在 OPTIONS 预检请求中发送cookie，因此所有调用均失败.

在客户端，我们使用 fetch() API和凭据:"include" .

我在这里想念什么?

解决方案

浏览器永远不会在飞行前 OPTIONS 请求中发送Cookie.因此，问题描述的是预期的行为.而且浏览器之所以不会在飞行前发送Cookie是因为CORS协议规范要求浏览器从飞行前排除Cookie和所有其他标准凭据(例如，Authorization标头).请参见 fetch.spec.whatwg/#ref-for-credentials％E2％91％A5 ，其中指出:

CORS预检请求从不包含凭据

…，另请参见答案 stackoverflow/a/50959576/441757 ..>

因此，将预检发送到的服务器必须配置为允许未经身份验证的 OPTIONS 请求-并且即使请求未通过，也必须以200 OK响应 OPTIONS 请求.不得包含任何Cookie或其他凭据.这是CORS协议的基本要求.

Two components:

A React single page app on react.mycompany

A Apigee API proxy on apigee.proxy

On login Apigee sets a jwt cookie using the Set-Cookie header:

Set-Cookie: jwt={jwtoken};secure;httponly;path=/;samesite=none

On client side Chrome shows me this cookie for the frame react.mycompany:

name: jwt value: XXX domain: apigee.proxy path: / httpOnly: true secure: true sameSite: none

Now on non-auth requests Apigee checks the presence of the jwt cookie before processing the request.

The cookie is not sent on the OPTIONS preflight request and therefore all calls fail.

On client side we use the fetch() API with credentials: 'include'.

What am I missing here?

解决方案

Browsers don’t ever send cookies in preflight OPTIONS requests. So what the question describes is expected behavior. And the reason browsers don’t send cookies in the preflight is because the spec for the CORS protocol requires browsers to exclude cookies and all other standard credentials (e.g., the Authorization header) from the preflight. See fetch.spec.whatwg/#ref-for-credentials%E2%91%A5, which states:

a CORS-preflight request never includes credentials

…and see also the answer a stackoverflow/a/50959576/441757.

So the server the preflight is sent to must be configured to allow unauthenticated OPTIONS requests — and must respond to OPTIONS requests with a 200 OK even if a request doesn’t include any cookies or other credentials. That’s a fundamental requirement of the CORS protocol.