Việc trình duyệt chặn cookie của bên thứ ba, chế độ cài đặt của người dùng và phân vùng bộ nhớ gây ra một thách thức cho những trang web và dịch vụ dựa vào cookie và bộ nhớ khác trong các bối cảnh được nhúng, cho hành trình của người dùng như xác thực. Storage Access API (SAA) cho phép các trường hợp sử dụng này tiếp tục hoạt động, đồng thời hạn chế tối đa việc theo dõi trên nhiều trang web.
Trạng thái triển khai
Storage Access API có trong tất cả các trình duyệt chính, nhưng có một số điểm khác biệt nhỏ về cách triển khai giữa các trình duyệt. Những điểm khác biệt này đã được làm nổi bật trong các phần liên quan của bài đăng này.
Chúng tôi vẫn đang nỗ lực giải quyết tất cả các vấn đề chặn còn lại trước khi chuẩn hoá API.
Storage Access API là gì?
Storage Access API là một JavaScript API cho phép iframe yêu cầu quyền truy cập vào bộ nhớ khi quyền truy cập sẽ bị từ chối theo chế độ cài đặt của trình duyệt. Các thành phần nhúng có trường hợp sử dụng phụ thuộc vào việc tải tài nguyên trên nhiều trang web có thể sử dụng API này để yêu cầu người dùng cấp quyền truy cập khi cần.
Nếu yêu cầu lưu trữ được cấp, thì iframe sẽ có quyền truy cập vào cookie và bộ nhớ chưa được phân vùng của iframe. Những cookie và bộ nhớ này cũng có sẵn khi người dùng truy cập vào iframe dưới dạng một trang web cấp cao nhất.
Storage Access API cho phép cung cấp quyền truy cập vào bộ nhớ và cookie chưa được phân vùng cụ thể mà không gây nhiều phiền toái cho người dùng cuối, đồng thời vẫn ngăn chặn quyền truy cập vào bộ nhớ và cookie chưa được phân vùng chung (thường được dùng để theo dõi người dùng).
Trường hợp sử dụng
Một số thành phần nhúng của bên thứ ba cần có quyền truy cập vào cookie hoặc bộ nhớ chưa được phân vùng để mang lại trải nghiệm tốt hơn cho người dùng. Đây là điều không thể thực hiện được khi cookie của bên thứ ba bị hạn chế và tính năng phân vùng bộ nhớ được bật.
Các trường hợp sử dụng bao gồm:
- Tiện ích bình luận được nhúng yêu cầu thông tin chi tiết về phiên đăng nhập.
- Các nút "Thích" trên mạng xã hội yêu cầu thông tin chi tiết về phiên đăng nhập.
- Tài liệu được nhúng yêu cầu thông tin chi tiết về phiên đăng nhập.
- Trải nghiệm cao cấp được cung cấp cho một video được nhúng (ví dụ: không hiển thị quảng cáo cho người dùng đã đăng nhập hoặc biết lựa chọn ưu tiên của người dùng về phụ đề hoặc hạn chế một số loại video).
- Hệ thống thanh toán được nhúng.
Nhiều trường hợp sử dụng trong số này liên quan đến việc duy trì quyền truy cập đăng nhập trong iframe được nhúng.
Trường hợp nên sử dụng Storage Access API thay vì các API khác
Storage Access API là một trong những lựa chọn thay thế cho việc sử dụng cookie và bộ nhớ chưa được phân vùng. Vì vậy, bạn cần hiểu rõ thời điểm nên sử dụng API này so với các API khác. Tính năng này dành cho các trường hợp sử dụng mà cả hai điều kiện sau đều đúng:
- Người dùng sẽ tương tác với nội dung được nhúng, tức là nội dung đó không phải là iframe thụ động hoặc iframe ẩn.
- Người dùng đã truy cập vào nguồn gốc được nhúng trong một bối cảnh cấp cao nhất, tức là khi nguồn gốc đó không được nhúng trong một trang web khác.
Có các API thay thế cho nhiều trường hợp sử dụng:
- Cookie có trạng thái được phân vùng độc lập (CHIPS) cho phép nhà phát triển chọn sử dụng cookie cho bộ nhớ "được phân vùng", với một hũ cookie riêng cho mỗi trang web cấp cao nhất. Ví dụ: một tiện ích trò chuyện trên web của bên thứ ba có thể dựa vào việc đặt cookie để lưu thông tin về phiên. Thông tin phiên được lưu theo từng trang web, vì vậy, bạn không cần truy cập vào cookie do tiện ích đặt trên các trang web khác nơi tiện ích cũng được nhúng. Storage Access API rất hữu ích khi một tiện ích được nhúng của bên thứ ba phụ thuộc vào việc chia sẻ cùng một thông tin trên nhiều nguồn gốc (ví dụ: thông tin chi tiết về phiên đăng nhập hoặc lựa chọn ưu tiên).
- Phân vùng bộ nhớ là cách để iframe trên nhiều trang web sử dụng các cơ chế lưu trữ JavaScript hiện có trong khi phân chia bộ nhớ cơ bản cho mỗi trang web. Điều này ngăn chặn cùng một thành phần nhúng trên các trang web khác truy cập vào bộ nhớ được nhúng trong một trang web.
- Bộ trang web có liên quan (RWS) là một cách để tổ chức khai báo mối quan hệ giữa các trang web, nhờ đó trình duyệt cho phép truy cập hạn chế vào cookie và bộ nhớ chưa được phân vùng cho những mục đích cụ thể. Các trang web vẫn cần yêu cầu quyền truy cập bằng Storage Access API, nhưng đối với các trang web trong bộ, quyền truy cập có thể được cấp mà không cần lời nhắc đối với người dùng.
- Federated Credential Management (FedCM) là một phương pháp bảo đảm quyền riêng tư cho các dịch vụ nhận dạng liên kết. Storage Access API xử lý việc truy cập vào cookie và bộ nhớ chưa được phân vùng sau khi đăng nhập. Đối với một số trường hợp sử dụng, FedCM cung cấp một giải pháp thay thế cho Storage Access API và có thể được ưu tiên hơn vì có lời nhắc của trình duyệt hướng đến việc đăng nhập nhiều hơn. Tuy nhiên, việc áp dụng FedCM thường đòi hỏi bạn phải thay đổi thêm mã, chẳng hạn như để hỗ trợ các điểm cuối HTTP của FedCM.
- Ngoài ra, còn có các API chống gian lận, liên quan đến quảng cáo và đo lường. Storage Access API không nhằm giải quyết những vấn đề này.
Sử dụng Storage Access API
Storage Access API có 2 phương thức dựa trên lời hứa:
Document.hasStorageAccess()
(cũng có tên mới làDocument.hasUnpartitionedCookieAccess()
kể từ Chrome 125)Document.requestStorageAccess()
Thư viện này cũng tích hợp với Permissions API. Thao tác này cho phép bạn kiểm tra trạng thái của quyền truy cập vào bộ nhớ trong bối cảnh của bên thứ ba, cho biết liệu lệnh gọi đến document.requestStorageAccess()
có được tự động cấp hay không:
Sử dụng phương thức hasStorageAccess()
Khi tải lần đầu, một trang web có thể sử dụng phương thức hasStorageAccess()
để kiểm tra xem quyền truy cập vào cookie của bên thứ ba đã được cấp hay chưa.
// Set a hasAccess boolean variable which defaults to false.
let hasAccess = false;
async function handleCookieAccessInit() {
if (!document.hasStorageAccess) {
// Storage Access API is not supported so best we can do is
// hope it's an older browser that doesn't block 3P cookies.
hasAccess = true;
} else {
// Check whether access has been granted using the Storage Access API.
hasAccess = await document.hasStorageAccess();
if (!hasAccess) {
// Handle the lack of access (covered later)
}
}
if (hasAccess) {
// Use the cookies.
}
}
handleCookieAccessInit();
Storage Access API chỉ cấp quyền truy cập bộ nhớ cho tài liệu iframe sau khi gọi requestStorageAccess(),
, vì vậy, ban đầu hasStorageAccess()
có thể trả về giá trị false, chẳng hạn như nếu người dùng chặn cookie của bên thứ ba theo mặc định.
(Tuy nhiên, chế độ cài đặt dành riêng cho người dùng trên từng trang web cũng có thể cho phép truy cập cookie trên một trang web cụ thể, ngay cả khi người dùng chặn cookie của bên thứ ba theo mặc định.)
Quyền truy cập bộ nhớ bằng API này được duy trì trong các thao tác điều hướng cùng nguồn bên trong iframe, đặc biệt là để cho phép tải lại sau khi cấp quyền truy cập cho những trang yêu cầu phải có cookie trong yêu cầu ban đầu đối với tài liệu HTML.
Sử dụng requestStorageAccess()
Nếu không có quyền truy cập, iframe có thể cần yêu cầu quyền truy cập bằng phương thức requestStorageAccess()
:
if (!hasAccess) {
try {
await document.requestStorageAccess();
} catch (err) {
// Access was not granted and it may be gated behind an interaction
return;
}
}
Vào lần đầu tiên yêu cầu này được đưa ra, người dùng có thể cần phê duyệt quyền truy cập này bằng một lời nhắc của trình duyệt, sau đó, lời hứa sẽ được giải quyết hoặc sẽ từ chối dẫn đến một ngoại lệ nếu await
được sử dụng.
Để ngăn chặn hành vi sai trái, lời nhắc này trên trình duyệt sẽ chỉ xuất hiện sau khi người dùng tương tác. Đó là lý do requestStorageAccess()
ban đầu cần được gọi từ một trình xử lý sự kiện do người dùng kích hoạt, thay vì ngay khi iframe tải:
async function doClick() {
// Only do this extra check if access hasn't already been given
// based on the hasAccess variable.
if (!hasAccess) {
try {
await document.requestStorageAccess();
hasAccess = true; // Can assume this was true if requestStorageAccess() did not reject.
} catch (err) {
// Access was not granted.
return;
}
}
if (hasAccess) {
// Use the cookies
}
}
document.querySelector('#my-button').addEventListener('click', doClick);
Lời nhắc cấp quyền
Khi người dùng nhấp vào nút này lần đầu tiên, lời nhắc của trình duyệt sẽ tự động xuất hiện trong hầu hết các trường hợp, thường là trong thanh địa chỉ. Ảnh chụp màn hình sau đây cho thấy ví dụ về lời nhắc của Chrome, nhưng các trình duyệt khác cũng có giao diện người dùng tương tự:

Trình duyệt có thể bỏ qua lời nhắc và tự động cấp quyền trong một số trường hợp:
- Nếu trang và iframe đã được sử dụng trong 30 ngày qua sau khi bạn chấp nhận lời nhắc.
- Nếu iframe được nhúng là một phần của Bộ trang web có liên quan.
- Nếu FedCM được dùng làm tín hiệu tin cậy để truy cập vào bộ nhớ.
- Trong Firefox, lời nhắc cũng sẽ bị bỏ qua đối với các trang web đã biết (những trang web mà bạn đã tương tác ở cấp cao nhất) trong 5 lần đầu tiên.
Ngoài ra, phương thức này có thể tự động bị từ chối mà không hiển thị lời nhắc trong một số trường hợp:
- Nếu trước đây người dùng chưa từng truy cập và tương tác với trang web sở hữu iframe dưới dạng tài liệu cấp cao nhất, chứ không phải trong iframe. Điều này có nghĩa là Storage Access API chỉ hữu ích cho những trang web được nhúng mà người dùng đã từng truy cập trong bối cảnh bên thứ nhất.
- Nếu phương thức
requestStorageAccess()
được gọi bên ngoài một sự kiện tương tác của người dùng mà không có sự phê duyệt trước về lời nhắc sau một lượt tương tác.
Mặc dù người dùng sẽ được nhắc trong lần sử dụng đầu tiên, nhưng các lần truy cập tiếp theo có thể phân giải requestStorageAccess()
mà không cần lời nhắc và không yêu cầu người dùng tương tác trong Chrome và Firefox. Xin lưu ý rằng Safari luôn yêu cầu người dùng tương tác.
Vì quyền truy cập vào cookie và bộ nhớ có thể được cấp mà không cần lời nhắc hoặc sự tương tác của người dùng, nên bạn thường có thể truy cập vào cookie hoặc bộ nhớ chưa được phân vùng trước khi người dùng tương tác trên các trình duyệt hỗ trợ tính năng này (Chrome và Firefox) bằng cách gọi requestStorageAccess()
khi tải trang. Điều này có thể cho phép bạn truy cập ngay vào cookie và bộ nhớ chưa được phân vùng, đồng thời mang đến trải nghiệm đầy đủ hơn, ngay cả trước khi người dùng tương tác với iframe. Trong một số trường hợp, điều này có thể mang lại trải nghiệm người dùng tốt hơn so với việc chờ người dùng tương tác.
FedCM dưới dạng một tín hiệu đáng tin cậy cho SAA
FedCM (Federated Credential Management) là một phương pháp bảo đảm quyền riêng tư cho các dịch vụ nhận dạng liên kết (chẳng hạn như "Đăng nhập bằng...") mà không dựa vào cookie của bên thứ ba hoặc lệnh chuyển hướng điều hướng.
Khi người dùng đăng nhập vào một Bên phụ thuộc (RP) có một số nội dung được nhúng từ nhà cung cấp dịch vụ danh tính (IdP) bên thứ ba bằng FedCM, nội dung IdP được nhúng có thể tự động có quyền truy cập vào bộ nhớ đối với các cookie chưa phân vùng cấp cao nhất của riêng nội dung đó. Để bật quyền truy cập tự động vào bộ nhớ bằng FedCM, bạn phải đáp ứng các điều kiện sau:
- Xác thực FedCM (trạng thái đăng nhập của người dùng) phải đang hoạt động.
- RP đã chọn tham gia bằng cách đặt quyền
identity-credentials-get
, ví dụ:
<iframe src="https://idp.example" allow="identity-credentials-get"></iframe>
Ví dụ: iframe idp.example
được nhúng trong rp.example
. Khi người dùng đăng nhập bằng FedCM, iframe idp.example
có thể yêu cầu quyền truy cập vào bộ nhớ cho cookie cấp cao nhất của riêng iframe đó.
rp.example
thực hiện một lệnh gọi FedCM để đăng nhập người dùng bằng nhà cung cấp dịch vụ danh tính idp.example
:
// The user will be asked to grant FedCM permission.
const cred = await navigator.credentials.get({
identity: {
providers: [{
configURL: 'https://idp.example/fedcm.json',
clientId: '123',
}],
},
});
Sau khi người dùng đăng nhập, IdP có thể gọi requestStorageAccess()
từ trong iframe idp.example
, miễn là RP đã cho phép rõ ràng việc này bằng Permissions Policy (Chính sách về quyền).
Hoạt động nhúng sẽ tự động được cấp quyền truy cập vào bộ nhớ cho cookie cấp cao nhất của riêng nó, mà không cần người dùng kích hoạt hoặc cần một lời nhắc cấp quyền khác:
// Make this call within the embedded IdP iframe:
// No user gesture is needed, and the storage access will be auto-granted.
await document.requestStorageAccess();
// This returns `true`.
const hasAccess = await document.hasStorageAccess();
Quyền này sẽ chỉ được tự động cấp miễn là người dùng đăng nhập bằng FedCM. Sau khi quá trình xác thực không hoạt động, các yêu cầu tiêu chuẩn về SAA sẽ được áp dụng để cấp quyền truy cập vào bộ nhớ.
Storage Access API cho bộ nhớ không dùng cookie
Bạn có thể yêu cầu quyền truy cập vào bộ nhớ cục bộ không phân vùng bằng cách truyền tham số types
vào lệnh gọi requestStorageAccess
. Ví dụ: để yêu cầu quyền truy cập vào bộ nhớ cục bộ chưa được phân vùng, bạn có thể gọi requestStorageAccess({localStorage: true})
.
Nếu cookie của bên thứ ba được bật, phương thức này sẽ cấp quyền truy cập mà không yêu cầu người dùng kích hoạt hoặc bất kỳ lời nhắc nào về quyền. Nếu người dùng đã tắt cookie của bên thứ ba, thì người dùng sẽ phải được nhắc trước khi được cấp quyền truy cập vào bộ nhớ.

Trước tiên, hãy kiểm tra xem trình duyệt đã có quyền truy cập vào bộ nhớ hay chưa:
async function hasCookieAccess(){
// Check if Storage Access API is supported
if (!document.requestStorageAccess) {
// Storage Access API is not supported, so we assume it's an older browser that doesn't partition storage.
throw new Error("requestStorageAccess is not supported")
}
// Check if access has already been granted or if the user has 3-party cookies enabled
return document.hasStorageAccess();
}
Nếu bạn đã bật cookie của bên thứ ba, hãy yêu cầu quyền truy cập vào bộ nhớ:
// Request storage access and return the storage handle
async function requestStorageHandle(){
// You can request for multiple types of non-cookie storage
// at once, or request for all of them with all:true
return document.requestStorageAccess({all:true});
}
Nếu cookie của bên thứ ba bị chặn (ví dụ: ở chế độ ẩn danh), hãy kiểm tra quyền truy vấn để quyết định xem có cần lời nhắc cho người dùng hay không. Trạng thái quyền navigator.permissions.query({name: 'storage-access'})
có thể có các giá trị sau:
granted
. Người dùng đã cấp quyền truy cập. GọirequestStorageAccess
để có quyền truy cập vào bộ nhớ chưa phân vùng mà không cần thêm lời nhắc cho người dùng.prompt
. Người dùng chưa cấp quyền truy cập. Đặt một trình nghe lượt nhấp và gọi lạirequestStorageAccess
sau khi người dùng tương tác.error
. Quyền này không được hỗ trợ. Khi Storage Access API được hỗ trợ, có thể quyền này cũng được hỗ trợ.
// Returns `granted`, or `prompt`; or throws an error if storage-access
// permission is not supported
async function getStorageAccessPermission(){
// Check the storage-access permission
// Wrap this in a try/catch for browsers that support the
// Storage Access API but not this permission check
return navigator.permissions.query({name: 'storage-access'});
}
Bạn có thể triển khai quy trình hoàn chỉnh để xử lý bộ nhớ được phân vùng không có cookie như sau:
async function getStorageHandle() {
// Check if the user has 3-party cookie access
if (await hasCookieAccess()) {
// If the user has access, requestStorageAccess() will resolve automatically
return requestStorageHandle();
}
// If the browser blocks third party cookies, check if the user has
// accepted the prompt and granted access. If they have,
// requestStorageAccess() will resolve automatically
const permission = await getStorageAccessPermission();
if (permission == 'granted') { // User has seen prompt and granted access
return requestStorageHandle();
}
// Wait for user activation to prompt the user again
// (or put your silent failure logic here instead)
return new Promise((resolve, reject) => {
document.querySelector('#myButton').addEventListener(e => {
requestStorageHandle().then(resolve, reject);
})
})
}
// Use your storage
getStorageHandle().then(handle=>{
handle.indexedDB.open(...);
}).catch(() => {
// If the promise is rejected, you can use regular partitioned storage
indexedDB.open(...);
})
Tải các tệp tiếp theo bằng Tiêu đề truy cập vào bộ nhớ
Tiêu đề Storage Access là một cách được đề xuất và hiệu quả hơn để cho phép tải nội dung được nhúng, bao gồm cả các tài nguyên không phải iframe. Tính năng này có trong Chrome 133. Với Tiêu đề truy cập bộ nhớ, trình duyệt có thể nhận ra khi người dùng đã cấp quyền storage-access
cho nguồn gốc bên thứ ba trong bối cảnh hiện tại và có thể tải tài nguyên có quyền truy cập vào cookie chưa phân vùng trong các lần truy cập tiếp theo.
Luồng tiêu đề truy cập bộ nhớ
Với Storage Access Headers, các lượt truy cập trang tiếp theo sẽ kích hoạt quy trình sau:
- Trước đây, người dùng đã truy cập vào
website.example
nhúng tài nguyêncalendar.example
và cấpstorage-access
bằng lệnh gọidocument.requestStorageAccess()
. - Người dùng truy cập lại vào
website.example
có tài nguyêncalendar.example
được nhúng một lần nữa. Yêu cầu này vẫn chưa có quyền truy cập vào cookie, như trước đây. Tuy nhiên, người dùng đã cấp quyềnstorage-access
trước đó và lệnh tìm nạp bao gồm một tiêu đềSec-Fetch-Storage-Access: inactive
để cho biết rằng quyền truy cập vào cookie chưa được phân vùng có sẵn nhưng chưa được kích hoạt. - Máy chủ
calendar.example
phản hồi bằng tiêu đềActivate-Storage-Access: retry; allowed-origin='<origin>'
(trong trường hợp này,<origin>
sẽ làhttps://website.example
) để cho biết rằng quá trình tìm nạp tài nguyên yêu cầu sử dụng cookie không phân vùng với quyềnstorage-access
. - Trình duyệt sẽ thử lại yêu cầu, lần này bao gồm cả cookie chưa phân vùng (kích hoạt quyền
storage-access
cho lần tìm nạp này và các lần tìm nạp tiếp theo). - Máy chủ
calendar.example
phản hồi bằng nội dung iframe được cá nhân hoá. Phản hồi này bao gồm một tiêu đềActivate-Storage-Access: load
để cho biết rằng trình duyệt sẽ tải nội dung khi quyềnstorage-access
được kích hoạt (nói cách khác, tải với quyền truy cập cookie không phân vùng, như thểdocument.requestStorageAccess()
đã được gọi). - Tác nhân người dùng tải nội dung iframe có quyền truy cập vào cookie không được phân vùng bằng quyền
storage-access
. Sau bước này, tiện ích có thể hoạt động như mong đợi.

Sử dụng tiêu đề truy cập vào bộ nhớ
Bảng sau đây liệt kê các tiêu đề Storage Access.
Flow | Tiêu đề | Giá trị | Mô tả |
---|---|---|---|
Yêu cầu |
Sec-Fetch-Storage-Access Lưu ý: Trình duyệt sẽ tự động gửi tiêu đề này trong các yêu cầu trên nhiều trang web bao gồm cả thông tin đăng nhập (ví dụ: new Request('request.example', { credentials: 'include' }); ).
|
none |
Ứng dụng nhúng không có quyền truy cập vào bộ nhớ. |
inactive |
Nội dung nhúng có quyền nhưng không sử dụng quyền đó. Yêu cầu cũng phải có tiêu đề Origin .
|
||
active |
Hoạt động nhúng có quyền truy cập vào cookie không được phân vùng. | ||
Phản hồi | Activate-Storage-Access |
load |
Hướng dẫn trình duyệt cấp cho trình nhúng quyền truy cập vào cookie chưa được phân vùng cho tài nguyên được yêu cầu. Việc thêm tiêu đề này tương đương với việc gọi document.requestStorageAccess()
nếu quyền storage-access đã được cấp. Điều này có nghĩa là người dùng sẽ không thấy lời nhắc bổ sung nào.
|
retry |
Hướng dẫn trình duyệt kích hoạt quyền truy cập vào bộ nhớ, sau đó thử lại yêu cầu. | ||
allowed-origin |
<origin> |
Chỉ định nguồn nào được phép bắt đầu các yêu cầu có thông tin đăng nhập (ví dụ: https://site.example hoặc * ). |
Ví dụ: bạn có thể dùng Tiêu đề truy cập bộ nhớ để tải hình ảnh từ bên thứ ba:
// On the client side
<img src="https://server.example/image">
Trong trường hợp này, server.example
sẽ triển khai logic sau ở phía máy chủ:
app.get('/image', (req, res) => {
const storageAccessHeader = req.headers['sec-fetch-storage-access'];
if (storageAccessHeader === 'inactive') {
// The user needs to grant permission, trigger a prompt
// Check if the requesting origin is allowed
// to send credentialed requests to this server.
// Assuming the `validate_origin(origin)` method is previously defined:
if (!validate_origin(req.headers.origin)) {
res.status(401).send(req.headers.origin +
' is not allowed to send credentialed requests to this server.');
return;
}
// 'retry' header value indicates that the content load request should be re-sent after the user has granted permissions
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')
}
});
Bản minh hoạ Storage Access API nhúng nội dung của bên thứ ba (bao gồm cả hình ảnh không phải iframe) bằng cách sử dụng Storage Access Headers.
Sử dụng truy vấn quyền storage-access
Để kiểm tra xem có thể cấp quyền mà không cần người dùng tương tác hay không, bạn có thể kiểm tra trạng thái của quyền storage-access
và chỉ thực hiện lệnh gọi requestStoreAccess()
sớm nếu không cần hành động của người dùng, thay vì gọi quyền này và khiến quyền đó không thành công khi cần có một lượt tương tác.
Điều này cũng giúp bạn có thể xử lý nhu cầu về lời nhắc ngay từ đầu bằng cách hiển thị nội dung khác, chẳng hạn như nút đăng nhập.
Đoạn mã sau đây thêm quy trình kiểm tra quyền storage-access
vào ví dụ trước đó:
// Set a hasAccess boolean variable which defaults to false except for
// browsers which don't support the API - where we assume
// such browsers also don't block third-party cookies.
let hasAccess = false;
async function hasCookieAccess() {
// Check if Storage Access API is supported
if (!document.requestStorageAccess) {
// Storage Access API is not supported so best we can do is
// hope it's an older browser that doesn't block 3P cookies.
return true;
}
// Check if access has already been granted
if (await document.hasStorageAccess()) {
return true;
}
// Check the storage-access permission
// Wrap this in a try/catch for browsers that support the
// Storage Access API but not this permission check
// (e.g. Safari and earlier versions of Firefox).
let permission;
try {
permission = await navigator.permissions.query(
{name: 'storage-access'}
);
} catch (error) {
// storage-access permission not supported. Assume no cookie access.
return false;
}
if (permission) {
if (permission.state === 'granted') {
// Permission has previously been granted so can just call
// requestStorageAccess() without a user interaction and
// it will resolve automatically.
try {
await document.requestStorageAccess();
return true;
} catch (error) {
// This shouldn't really fail if access is granted, but return false
// if it does.
return false;
}
} else if (permission.state === 'prompt') {
// Need to call requestStorageAccess() after a user interaction
// (potentially with a prompt). Can't do anything further here,
// so handle this in the click handler.
return false;
} else if (permission.state === 'denied') {
// Not used: see https://github.com/privacycg/storage-access/issues/149
return false;
}
}
// By default return false, though should really be caught by earlier tests.
return false;
}
async function handleCookieAccessInit() {
hasAccess = await hasCookieAccess();
if (hasAccess) {
// Use the cookies.
}
}
handleCookieAccessInit();
Iframe dạng hộp cát
Khi sử dụng Storage Access API trong iframe được tạo hộp cát, bạn cần có các quyền sau đây đối với hộp cát:
- Bạn phải cho phép
allow-storage-access-by-user-activation
truy cập vào Storage Access API. - Bạn phải có
allow-scripts
để cho phép sử dụng JavaScript gọi API. allow-same-origin
là bắt buộc để cho phép truy cập vào cookie và bộ nhớ khác có cùng nguồn gốc.
Ví dụ:
<iframe sandbox="allow-storage-access-by-user-activation
allow-scripts
allow-same-origin"
src="..."></iframe>
Yêu cầu về cookie
Để được truy cập bằng Storage Access API trong Chrome, cookie trên nhiều trang web phải được đặt bằng 2 thuộc tính sau:
SameSite=None
– bắt buộc phải có để đánh dấu cookie là cookie trên nhiều trang webSecure
– đảm bảo chỉ những cookie do các trang web HTTPS đặt mới có thể truy cập được.
Trong Firefox và Safari, cookie được đặt mặc định thành SameSite=None
và không hạn chế SAA đối với cookie Secure
nên các thuộc tính này không bắt buộc. Bạn nên chỉ định rõ ràng về thuộc tính SameSite
và luôn sử dụng cookie Secure
.
Quyền truy cập vào trang cấp cao nhất
Storage Access API được thiết kế để cho phép truy cập vào cookie của bên thứ ba trong iframe được nhúng.
Ngoài ra, còn có những trường hợp sử dụng khác khi trang cấp cao nhất cần có quyền truy cập vào cookie của bên thứ ba. Ví dụ: hình ảnh hoặc tập lệnh bị hạn chế bởi cookie, mà chủ sở hữu trang web có thể muốn đưa trực tiếp vào tài liệu cấp cao nhất thay vì trong iframe. Để giải quyết trường hợp sử dụng này, Chrome đã đề xuất một tiện ích cho Storage Access API, trong đó thêm phương thức requestStorageAccessFor()
.
Phương thức requestStorageAccessFor()
Phương thức requestStorageAccessFor()
hoạt động tương tự như requestStorageAccess()
nhưng dành cho các tài nguyên cấp cao nhất. Bạn chỉ có thể sử dụng API này cho các trang web trong Bộ trang web có liên quan để ngăn việc cấp quyền truy cập chung vào cookie của bên thứ ba.
Để biết thêm thông tin về cách sử dụng requestStorageAccessFor()
, hãy đọc Bộ trang web có liên quan: hướng dẫn dành cho nhà phát triển.
Truy vấn quyền top-level-storage-access
Browser Support
Tương tự như quyền storage-access
, có quyền top-level-storage-access
để kiểm tra xem có thể cấp quyền truy cập cho requestStorageAccessFor()
hay không.
Storage Access API khác biệt như thế nào khi được dùng với RWS?
Khi Bộ trang web có liên quan được dùng với Storage Access API, một số chức năng bổ sung nhất định sẽ có sẵn như được nêu chi tiết trong bảng sau:
Không có RWS | Có RWS | |
---|---|---|
Yêu cầu người dùng thực hiện một cử chỉ để bắt đầu yêu cầu quyền truy cập vào bộ nhớ | ||
Yêu cầu người dùng truy cập vào nguồn gốc bộ nhớ được yêu cầu trong một bối cảnh cấp cao nhất trước khi cấp quyền truy cập | ||
Người dùng có thể bỏ qua lời nhắc cho người dùng lần đầu | ||
Không cần gọi requestStorageAccess nếu quyền truy cập đã được cấp trước đó |
||
Tự động cấp quyền truy cập trên các miền khác trong một Bộ trang web có liên quan | ||
Hỗ trợ requestStorageAccessFor để truy cập vào trang cấp cao nhất |
Bản minh hoạ: thiết lập và truy cập vào cookie
Bản minh hoạ sau đây cho thấy cách truy cập vào một cookie do chính bạn đặt trong màn hình đầu tiên của bản minh hoạ trong một khung được nhúng trong trang web thứ hai của bản minh hoạ:
storage-access-api-demo.glitch.me
Bản minh hoạ này yêu cầu trình duyệt phải tắt cookie của bên thứ ba:
- Chrome 118 trở lên có cờ
chrome://flags/#test-third-party-cookie-phaseout
được đặt và trình duyệt đã khởi động lại. - Firefox
- Safari
Bản minh hoạ: thiết lập Bộ nhớ cục bộ
Bản minh hoạ sau đây cho thấy cách truy cập vào các Kênh truyền tin không phân vùng từ iframe của bên thứ ba bằng Storage Access API:
https://saa-beyond-cookies.glitch.me/
Bản minh hoạ này yêu cầu Chrome 125 trở lên và phải bật cờ test-third-party-cookie-phaseout.
Tài nguyên
- Đọc quy cách cung cấp quyền truy cập vào cookie của bên thứ ba hoặc theo dõi và nêu vấn đề.
- Đọc quy cách cung cấp quyền truy cập vào bộ nhớ không phân vùng hoặc theo dõi và nêu vấn đề.
- Tài liệu về API và hướng dẫn.
- Tài liệu của Chrome về cách sử dụng Storage Access API trong Bộ trang web có liên quan