CORS 是 Web 上的一种标准机制，它使来自 Web 应用程序的跨域请求能够到达不同域上的服务器。 cross original 请求也可以被认为是 cross domain 请求。 只要响应中没有所需的 HTTP 标头，浏览器就会阻止跨域请求。
响应标头由服务器指定，这就是为什么必须设置服务器以生成正确的标头。 在 SAP Commerce Cloud 后端，可以使用 CorsFilter 以通用方式配置这些标头。 Project properties 可用于为每个节点配置此项，或者 ImpEx 安装脚本可用于安装到每个节点。
匿名同意功能需要 x-anonymous-consents 标头。 如果不使用匿名同意，则可以省略此配置。 但是，需要注意的是，如果您不包含此标头，则必须禁用匿名同意功能。 否则，您可能会遇到店面无法正常显示的问题。
allowCredentials
请求凭证与 cookie、授权标头或 TLS 客户端证书有关。这些默认情况下不允许在跨域请求中使用，这就是在未应用配置时请求被阻止的原因。
Spartacus 没有在 Spartacus 库的 1.x 版本中发送 cookie，但从 2.0 版本开始，将为每个 OCC 请求发送 cookie。这也已修补到 Spartacus 库的 1.4 和 1.5 版本。
需要发送 cookie 以获得 session affinity，也称为 sticky sessions. sticky sessions 意味着 API 端点后面的同一台服务器用于同一会话的所有后续请求。尽管 Commerce API 是无状态的，但有时多个并行或顺序调用可能会失败。例如，“添加到购物车”请求后跟“加载购物车”请求可能会失败，因为第一个请求可能会在服务器 1 上结束，而紧随其后的第二个请求可能会在服务器 2 上结束。服务器可能不足以快速发送缓存失效，这就是第二个响应可能无法捕获添加的项目的原因。
sticky sessions 的另一个优点是，如果同一会话的请求由同一台服务器提供服务，则后端将获得性能改进。
出于这个原因，CCv2 公开了一个响应 cookie (ROUTE)，它指示用于处理 API 请求的处理服务器。每当客户端将此 cookie 添加到下一个请求中时，该请求都由同一服务器处理。
- 在部署期间使用配置属性 -
configuration properties安装它们 - 在部署期间使用 Commerce Cloud nanifest 文件安装它们
- 使用 ImpEx 脚本在运行时安装它们
- 使用 Backoffice 在运行时手动配置它们
注意
-
OCC 由名为 commercewebservices 的模板扩展安装。 但是，可以重命名扩展 Web 应用程序路径，或从中生成自定义扩展。 在下一部分的示例中，我们假设名称为 commercewebservices，但如果有自定义名称，则应替换它。
-
大多数配置仅适用于 OCC，但如果您使用其他 API（例如
Assisted Service Module），还需要为这些 API 配置 CORS。 -
如果使用的是 SAP Commerce Cloud 版本 1905 或更早版本，则必须使用 ycommercewebservices（或自定义扩展名）而不是 commercewebservices。 如果使用的是 SAP Commerce Cloud 2005 或更高版本，则可以选择使用 commercewebservices 或 ycommercewebservices，但默认为 commercewebservices，由 cx 配方定义。
