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 配方定义。
