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，變更才會生效。