Chrome 將在 130 版中開始來源試用,將 HTTP 標頭新增至 Storage Access API (SAA):Storage Access Headers。新版 Sec-Fetch-Storage-Access
要求標頭和 Activate-Storage-Access
回應標頭旨在支援非 iframe 資源,並可為仰賴嵌入內容 (例如社群媒體小工具、日曆和互動式工具) 的網站改善效能和使用者體驗。
JavaScript 流程 (及其限制)
過去,即使使用者已授予權限,SAA 每次重新載入時,都會需要對 document.requestStorageAccess()
發出 JavaScript API 呼叫。這個方法雖然有效,但也設有下列限制:
- 多次網路往返:這個程序通常會涉及多次網路要求和網頁重新載入,嵌入式內容才能正常運作。
- IFrame 依附元件:JavaScript 執行作業必須使用 iframe 或 iframe 中的子資源,這會限制開發人員的彈性。
舉例來說,如果您只使用 JavaScript 將 calendar.example
的月曆小工具嵌入 website.example
,則該小工具的程式碼會如下所示:
- 載入預留位置:
website.example
會要求小工具。由於website.example
上嵌入的calendar.example
小工具無法存取未分割的 Cookie,因此系統會改為轉譯預留位置小工具。 - 要求權限:系統會載入預留位置,然後呼叫
document.requestStorageAccess()
要求storage-access
權限。 - 使用者選擇授予權限。
- 重新載入小工具:這次小工具會重新整理,並透過 Cookie 存取權載入個人化內容。
- 每當使用者造訪嵌入
calendar.example
小工具的網站時,流程看起來就會與步驟 1、2 和 4 相同。唯一的簡化是,使用者不必重新授予存取權。
此流程的效率不彰:如果使用者已經授予儲存空間權限,則初始 iframe 載入、document.requestStorageAccess()
呼叫、後續重新載入會非必要來建立延遲時間。
包含 HTTP 標頭的新流程
新的儲存空間存取標頭可讓嵌入式內容 (包括非 iframe 資源) 更有效率地載入。
如果使用者已授予權限,瀏覽器會在使用 Storage Access Headers 的情況下,自動擷取設定 Sec-Fetch-Storage-Access: inactive
要求標頭的資源。開發人員不必採取任何行動就能設定要求標頭。伺服器可以使用 Activate-Storage-Access: retry; allowed-origin=<origin>
標頭回應,瀏覽器會使用必要憑證重試要求。
要求標頭
Sec-Fetch-Storage-Access: <access-status>
當使用者造訪嵌入跨網站內容的網頁時,瀏覽器會在可能需要憑證 (例如 Cookie) 的跨網站要求中,自動加入 Sec-Fetch-Storage-Access
標頭。這個標頭會指出嵌入內容的 Cookie 存取權狀態。以下說明如何解讀其值:
none
:嵌入項目沒有storage-access
權限,因此無法存取未分區的 Cookie。inactive
:嵌入程式碼具有storage-access
權限,但未選擇使用該權限。嵌入內容沒有未分割的 Cookie 存取權。active
:嵌入有未分區的 Cookie 存取權。這個值會納入任何可存取未分割 Cookie 的跨來源要求。
回應標頭
Activate-Storage-Access: <retry-or-reload>
Activate-Storage-Access
標頭會指示瀏覽器使用 Cookie 重試要求,或是在啟用 SAA 的情況下直接載入資源。標頭可能的值如下:
load
:指示瀏覽器為要求資源授予未分區 Cookie 的存取權。retry
:伺服器回應瀏覽器應啟用儲存空間存取權限,然後重試要求。
Activate-Storage-Access: retry; allowed-origin="https://site.example"
Activate-Storage-Access: retry; allowed-origin=*
Activate-Storage-Access: load
支援非 iframe 資源
儲存空間存取標頭更新可讓 SAA 支援非 iframe 嵌入內容,例如在其他網域代管的圖片。在此之前,如果無法使用第三方 Cookie,則沒有任何網站平台 API 允許在瀏覽器中使用憑證載入這類資源。舉例來說,embedding-site.example
可以要求提供圖片:
<img src="https://server.example/image"/>
伺服器可以傳回內容或錯誤,具體取決於 Cookie 是否可用:
app.get('/image', (req, res) => {
const headers = req.headers;
const cookieHeader = headers.cookie;
// Check if the embed has the necessary cookie access
if (!cookieHeader || !cookieHeader.includes('foo')) {
// If the cookie is not present, check if the browser supports Storage Access headers
if (
'sec-fetch-storage-access' in headers &&
headers['sec-fetch-storage-access'] == 'inactive'
) {
// If the browser supports Storage Access API, retry the request with storage access enabled
res.setHeader('Activate-Storage-Access', 'retry; allowed-origin="https://embedding-site.example"');
}
res.status(401).send('No cookie!');
} else {
// If the cookie is available, check if the user is authorized to access the image
if (!check_authorization(cookieHeader)) {
return res.status(401).send('Unauthorized!');
}
// If the user is authorized, respond with the image file
res.sendFile("path/to/image.jpeg");
}
});
如果沒有可用的 Cookie,伺服器會檢查 Sec-Fetch-Storage-Access
要求標頭的值。如果這個值設為 inactive
,伺服器會傳回 Activate-Storage-Access: retry
標頭,表示應使用儲存空間存取權重試要求。如果沒有 Cookie,且 Sec-Fetch-Storage-Access
標頭的值不是 inactive,圖片就不會載入。
HTTP 標頭流程
透過 HTTP 標頭,瀏覽器可在使用者已授予小工具儲存空間存取權時,載入可存取未分割 Cookie 的 iframe,並在後續造訪期間存取該 iframe。
使用儲存空間存取權標頭後,後續的網頁造訪會觸發以下流程:
- 使用者再次造訪已嵌入
calendar.example
的website.example
。這項擷取作業目前仍無法存取這個 Cookie。不過,使用者先前已授予storage-access
權限,而擷取作業含有Sec-Fetch-Storage-Access: inactive
標頭,指出這項存取作業可以使用未分區的 Cookie,但並未使用。 calendar.example
伺服器會傳回Activate-Storage-Access: retry; allowed-origin=<origin>
標頭 (在本例中為<origin>
,此時為https://website.example
),表示擷取資源時必須使用具備儲存空間存取權的未分區 Cookie。- 瀏覽器會重試要求,這次會納入未分區的 Cookie (為此擷取作業啟用
storage-access
權限)。 calendar.example
伺服器會使用個人化的 iframe 內容回應。回應包含Activate-Storage-Access: load
標頭,用來指出瀏覽器應以啟用storage-access
權限的方式載入內容 (也就是使用未分割的 Cookie 存取權載入,就像呼叫document.requestStorageAccess()
一樣)。- 使用者代理程式會使用儲存空間存取權限,以未區隔的 Cookie 存取權載入 iframe 內容。完成這個步驟後,小工具就能正常運作。
更新解決方案
使用儲存空間存取標頭功能時,您可能會在下列兩種情況下更新程式碼:
- 您使用 SAA,且希望透過標頭邏輯提升成效。
- 您的驗證或邏輯取決於伺服器要求中是否包含
Origin
標頭。
實作 SAA 標頭邏輯
如要在解決方案中使用 Storage Access Headers,您必須更新解決方案。假設您是calendar.example
的擁有者,為了讓 website.example
能夠載入個人化的 calendar.example
小工具,小工具程式碼必須具備儲存空間存取權。
用戶端
對於現有解決方案,儲存空間存取標頭功能不需要在用戶端端進行任何程式碼更新。請參閱說明文件,瞭解如何實作 SAA。
伺服器端
在伺服器端,您可以使用新標頭:
app.get('/cookie-access-endpoint', (req, res) => {
const storageAccessHeader = req.headers['sec-fetch-storage-access'];
if (storageAccessHeader === 'inactive') {
// User needs to grant permission, trigger a prompt
if (!validate_origin(req.headers.origin)) {
res.status(401).send(`${req.headers.origin} is not allowed to send` +
' credentialed requests to this server.');
return;
}
res.set('Activate-Storage-Access', `retry; allowed-origin=${req.headers.origin}`);
res.status(401).send('This resource requires storage access. Please grant permission.');
} else if (storageAccessHeader === 'active') {
// User has granted permission, proceed with access
res.set('Activate-Storage-Access', 'load');
// Include the actual iframe content here
res.send('This is the content that requires cookie access.');
} else {
// Handle other cases (e.g., 'Sec-Fetch-Storage-Access': 'none')
}
});
如要瞭解這項解決方案的實際運作原理,請查看示範。
更新來源標頭邏輯
有了 Storage Access 標頭,Chrome 就會以比以往更多的方式傳送 Origin
標頭。如果伺服器端邏輯依賴 Origin 標頭,且只會在特定類型的要求 (例如 CORS 定義的) 中出現,這可能會影響邏輯。
為避免發生潛在問題,請檢查伺服器端程式碼:
- 檢查是否有任何驗證或邏輯取決於
Origin
標頭的存在。 - 更新程式碼,處理更多情況下出現的
Origin
標頭。
主要優點
儲存空間存取標頭是使用 SAA 的建議方式,可提供更佳效能。整體而言,這項異動帶來了以下幾項改善:
- 非 iframe 嵌入支援:針對更多資源啟用 SAA。
- 降低網路用量:要求較少,酬載也較少。
- 降低 CPU 用量:減少 JavaScript 處理作業。
- 改善使用者體驗:避免造成乾擾的中繼載入。
參與來源試用
來源試用計畫可讓您試用新功能,並針對可用性、實用性和成效提供意見回饋。詳情請參閱「開始使用原點試播」。
您可以註冊 Chrome 130 以上的來源試用版,試用儲存空間存取標頭功能。如要參加來源試用計畫,請按照下列步驟操作:
本機測試
您可以在本機測試儲存空間存取標頭功能,確保網站已做好準備,可以因應這項變更。
請按照下列步驟設定 Chrome 執行個體:
- 在
chrome://flags/#storage-access-headers
上啟用 Chrome 標記。 - 重新啟動 Chrome,變更才會生效。