Storage Access API

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

Browser Support

  • Chrome: 119.
  • Edge: 85.
  • Firefox: 65.
  • Safari: 11.1.

Source

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đ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:

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ự:

Lời nhắc về quyền truy cập vào bộ nhớ của Chrome Storage Access API.
Lời nhắc về quyền Storage Access API của Chrome

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ớ.

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ớ.

Lưu đồ cho Storage Access API, cho biết cách truy cập vào bộ nhớ không phải cookie.
Quy trình yêu cầu quyền truy cập vào bộ nhớ không phải cookie.

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ọi requestStorageAccess để 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ại requestStorageAccess 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:

  1. Trước đây, người dùng đã truy cập vào website.example nhúng tài nguyên calendar.example và cấp storage-access bằng lệnh gọi document.requestStorageAccess().
  2. Người dùng truy cập lại vào website.example có tài nguyên calendar.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ền storage-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.
  3. 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ền storage-access.
  4. 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).
  5. 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ền storage-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).
  6. 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.
Lưu đồ minh hoạ quy trình Tiêu đề truy cập bộ nhớ.
Sơ đồ quy trình Tiêu đề quyền truy cập vào bộ nhớ.

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>

Để đượ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 web
  • Secure – đả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()

Browser Support

  • Chrome: 119.
  • Edge: 119.
  • Firefox: not supported.
  • Safari: not supported.

Source

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

  • Chrome: 113.
  • Edge: 113.
  • Firefox: not supported.
  • Safari: not supported.

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
Sự khác biệt giữa việc sử dụng Storage Access API mà không có và có Bộ trang web có liên quan

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