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

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的SAP 电商云 Spartacus UI 的 CORS 设置的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。