Bộ trang web có liên quan (RWS) là một cơ chế nền tảng web giúp trình duyệt hiểu được mối quan hệ giữa một nhóm miền. Điều này cho phép trình duyệt đưa ra các quyết định quan trọng để bật một số chức năng của trang web (chẳng hạn như có cho phép truy cập vào cookie trên nhiều trang web hay không) và trình bày thông tin này cho người dùng.
Nhiều trang web dựa vào nhiều miền để cung cấp một trải nghiệm người dùng duy nhất. Các tổ chức có thể muốn duy trì nhiều miền cấp cao nhất cho nhiều trường hợp sử dụng, chẳng hạn như miền dành riêng cho từng quốc gia hoặc miền dịch vụ để lưu trữ hình ảnh hoặc video. Bộ trang web có liên quan cho phép các trang web chia sẻ dữ liệu trên nhiều miền, với các chế độ kiểm soát cụ thể.
Bộ trang web có liên quan là gì?
Ở cấp độ cao, Bộ trang web có liên quan là một tập hợp các miền, trong đó có một "tập hợp chính" duy nhất và có thể có nhiều "tập hợp thành viên".
Trong ví dụ sau, primary liệt kê miền chính và associatedSites liệt kê các miền đáp ứng yêu cầu của tập hợp con được liên kết.
{
"primary": "https://primary.com",
"associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}
Nhóm trang web có liên quan được liệt kê trong một tệp JSON công khai được lưu trữ trên GitHub. Đây là nguồn chính tắc cho tất cả các bộ được phê duyệt. Các trình duyệt sử dụng tệp này để xác định xem các trang web có thuộc cùng một Bộ trang web có liên quan hay không.
Chỉ những người có quyền quản trị đối với một miền mới có thể tạo một bộ bằng miền đó. Người gửi phải khai báo mối quan hệ giữa từng "set member" (thành viên trong bộ) với "set primary" (thành phần chính trong bộ). Các thành viên của tập hợp có thể bao gồm nhiều loại miền và phải thuộc về một tập hợp con dựa trên một trường hợp sử dụng.
Nếu ứng dụng của bạn phụ thuộc vào quyền truy cập vào cookie trên nhiều trang web (còn gọi là cookie của bên thứ ba) trên các trang web trong cùng một Nhóm trang web có liên quan, thì bạn có thể sử dụng Storage Access API (SAA) và requestStorageAccessFor API để yêu cầu quyền truy cập vào những cookie đó. Tuỳ thuộc vào tập hợp con mà mỗi trang web thuộc về, trình duyệt có thể xử lý yêu cầu theo cách khác.
Để tìm hiểu thêm về quy trình và các yêu cầu để gửi bộ, hãy xem hướng dẫn gửi. Các bộ đã gửi sẽ trải qua nhiều quy trình kiểm tra kỹ thuật để xác thực nội dung đã gửi.
Các trường hợp sử dụng Bộ trang web có liên quan
Bộ trang web có liên quan phù hợp với những trường hợp mà một tổ chức cần một hình thức nhận dạng chung trên nhiều trang web cấp cao nhất.
Sau đây là một số trường hợp sử dụng Bộ trang web có liên quan:
- Tuỳ chỉnh theo quốc gia. Khai thác các trang web được bản địa hoá trong khi dựa vào cơ sở hạ tầng dùng chung (ví dụ: example.co.uk có thể dựa vào một dịch vụ do example.ca lưu trữ).
- Tích hợp miền dịch vụ. Tận dụng các miền dịch vụ mà người dùng không bao giờ tương tác trực tiếp, nhưng cung cấp dịch vụ trên các trang web của cùng một tổ chức (ví dụ: example-cdn.com).
- Phân tách nội dung của người dùng. Truy cập vào dữ liệu trên nhiều miền tách biệt nội dung do người dùng tải lên với nội dung khác trên trang web vì lý do bảo mật, đồng thời cho phép miền được cách ly truy cập vào cookie xác thực (và các cookie khác). Nếu đang phân phát nội dung không hoạt động do người dùng tải lên, bạn cũng có thể lưu trữ nội dung đó một cách an toàn trên cùng một miền bằng cách làm theo các phương pháp hay nhất.
- Nội dung được xác thực và nhúng. Hỗ trợ nội dung được nhúng từ các tài sản liên kết (video, tài liệu hoặc tài nguyên chỉ dành cho người dùng đã đăng nhập trên trang web cấp cao nhất).
- Đăng nhập. Hỗ trợ đăng nhập trên các tài sản liên kết. API FedCM cũng có thể phù hợp với một số trường hợp sử dụng.
- Analytics. Triển khai hoạt động phân tích và đo lường hành trình của người dùng trên các tài sản liên kết để cải thiện chất lượng dịch vụ.
Thông tin chi tiết về việc tích hợp Bộ trang web có liên quan
Storage Access API
Storage Access API (SAA) cung cấp một cách để nội dung được nhúng trên nhiều nguồn có thể truy cập vào bộ nhớ mà nội dung đó thường chỉ có quyền truy cập trong bối cảnh của bên thứ nhất.
Các tài nguyên được nhúng có thể sử dụng các phương thức SAA để kiểm tra xem hiện tại chúng có quyền truy cập vào bộ nhớ hay không và yêu cầu quyền truy cập từ tác nhân người dùng.
Khi cookie của bên thứ ba bị chặn nhưng Bộ trang web có liên quan (RWS) được bật, Chrome sẽ tự động cấp quyền trong các bối cảnh nội bộ RWS và sẽ hiện lời nhắc cho người dùng trong các trường hợp khác. ("Bối cảnh nội bộ RWS" là một bối cảnh, chẳng hạn như iframe, có trang web được nhúng và trang web cấp cao nhất nằm trong cùng một RWS.)
Kiểm tra và yêu cầu quyền truy cập vào bộ nhớ
Để kiểm tra xem hiện tại các trang web được nhúng có quyền truy cập vào bộ nhớ hay không, bạn có thể dùng phương thức Document.hasStorageAccess().
Phương thức này trả về một lời hứa phân giải bằng một giá trị boolean cho biết liệu tài liệu đã có quyền truy cập vào cookie của tài liệu hay chưa. Lệnh hứa này cũng trả về giá trị true nếu iframe có cùng nguồn gốc với khung trên cùng.
Để yêu cầu quyền truy cập vào cookie trong ngữ cảnh nhiều trang web, các trang web được nhúng có thể sử dụng Document.requestStorageAccess() (rSA).
API requestStorageAccess() được gọi từ bên trong một iframe.
iframe đó phải vừa nhận được hoạt động tương tác của người dùng (một cử chỉ của người dùng, mà tất cả các trình duyệt đều yêu cầu), nhưng Chrome cũng yêu cầu rằng tại một thời điểm nào đó trong 30 ngày qua, người dùng đã truy cập vào trang web sở hữu iframe đó và đã tương tác cụ thể với trang web đó – dưới dạng một tài liệu cấp cao nhất, chứ không phải trong một iframe.
requestStorageAccess() trả về một lời hứa sẽ được thực hiện nếu quyền truy cập vào bộ nhớ được cấp. Lời hứa bị từ chối, nêu rõ lý do, nếu quyền truy cập bị từ chối vì bất kỳ lý do nào.
requestStorageAccessFor trong Chrome
Storage Access API chỉ cho phép các trang web được nhúng yêu cầu quyền truy cập vào bộ nhớ trong các phần tử <iframe> đã nhận được lượt tương tác của người dùng.
Điều này gây ra những thách thức trong việc áp dụng Storage Access API cho các trang web cấp cao nhất sử dụng hình ảnh hoặc thẻ tập lệnh trên nhiều trang web yêu cầu cookie.
Để giải quyết vấn đề này, Chrome đã triển khai một cách để các trang web cấp cao nhất yêu cầu quyền truy cập vào bộ nhớ thay cho các nguồn cụ thể bằng Document.requestStorageAccessFor() (rSAFor).
document.requestStorageAccessFor('https://target.site')
API requestStorageAccessFor() được gọi bởi một tài liệu cấp cao nhất. Tài liệu đó cũng phải vừa nhận được lượt tương tác của người dùng. Tuy nhiên, không giống như requestStorageAccess(), Chrome không kiểm tra xem có hoạt động tương tác nào trong tài liệu cấp cao nhất trong vòng 30 ngày qua hay không vì người dùng đã ở trên trang.
Kiểm tra quyền truy cập vào bộ nhớ
Quyền truy cập vào một số tính năng của trình duyệt (chẳng hạn như camera hoặc dịch vụ định vị vị trí) dựa trên quyền mà người dùng cấp. Permissions API cung cấp một cách để kiểm tra trạng thái quyền truy cập vào một API – liệu quyền đó đã được cấp, bị từ chối hay yêu cầu một số hình thức tương tác của người dùng, chẳng hạn như nhấp vào lời nhắc hoặc tương tác với trang.
Bạn có thể truy vấn trạng thái quyền bằng cách sử dụng navigator.permissions.query().
Để kiểm tra quyền truy cập vào bộ nhớ cho ngữ cảnh hiện tại, bạn cần truyền vào chuỗi 'storage-access':
navigator.permissions.query({name: 'storage-access'})
Để kiểm tra quyền truy cập vào bộ nhớ cho một nguồn gốc cụ thể, bạn cần truyền vào chuỗi 'top-level-storage-access':
navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})
Xin lưu ý rằng để bảo vệ tính toàn vẹn của nguồn gốc được nhúng, quy trình này chỉ kiểm tra các quyền do tài liệu cấp cao nhất cấp bằng cách sử dụng document.requestStorageAccessFor.
Tuỳ thuộc vào việc quyền có thể được cấp tự động hay yêu cầu một thao tác của người dùng, quyền sẽ trả về prompt hoặc granted.
Mô hình trên mỗi khung hình
Các quyền rSA được áp dụng cho mỗi khung. Các quyền rSA và rSAFor được coi là các quyền riêng biệt.
Mỗi khung hình mới sẽ cần yêu cầu quyền truy cập vào bộ nhớ riêng lẻ và quyền truy cập sẽ được tự động cấp. Chỉ yêu cầu đầu tiên mới cần cử chỉ của người dùng, mọi yêu cầu tiếp theo do iframe khởi tạo (chẳng hạn như điều hướng hoặc tài nguyên phụ) sẽ không cần đợi cử chỉ của người dùng vì yêu cầu ban đầu sẽ cấp quyền cho phiên duyệt web.
Việc làm mới, tải lại hoặc tạo lại iframe theo cách khác sẽ yêu cầu bạn yêu cầu cấp quyền truy cập lại.
Yêu cầu về cookie
Cookie phải chỉ định cả thuộc tính SameSite=None và Secure vì chỉ rSA mới cung cấp quyền truy cập cho những cookie đã được đánh dấu để sử dụng trong các bối cảnh trên nhiều trang web.
Cookie có SameSite=Lax, SameSite=Strict hoặc không có thuộc tính SameSite chỉ dành cho mục đích sử dụng của bên thứ nhất và sẽ không bao giờ được chia sẻ trong ngữ cảnh nhiều trang web, bất kể rSA.
Bảo mật
Đối với rSAFor, các yêu cầu về tài nguyên phụ yêu cầu tiêu đề Chia sẻ tài nguyên trên nhiều nguồn gốc (CORS) hoặc thuộc tính crossorigin trên các tài nguyên, đảm bảo người dùng chọn sử dụng một cách rõ ràng.
Ví dụ về cấu hình triển khai
Yêu cầu quyền truy cập vào bộ nhớ từ một iframe được nhúng trên nhiều nguồn gốc
requestStorageAccess() trong một thành phần nhúng trên một trang web khác.Kiểm tra xem bạn có quyền truy cập vào bộ nhớ hay không
Để kiểm tra xem bạn đã có quyền truy cập vào bộ nhớ hay chưa, hãy sử dụng document.hasStorageAccess().
Nếu lời hứa phân giải thành true, bạn có thể truy cập vào bộ nhớ trong bối cảnh trên nhiều trang web. Nếu giá trị này trả về false, bạn cần yêu cầu quyền truy cập vào bộ nhớ.
document.hasStorageAccess().then((hasAccess) => {
if (hasAccess) {
// You can access storage in this context
} else {
// You have to request storage access
}
});
Yêu cầu quyền truy cập vào bộ nhớ
Nếu bạn cần yêu cầu quyền truy cập vào bộ nhớ, trước tiên hãy kiểm tra quyền truy cập vào bộ nhớ navigator.permissions.query({name: 'storage-access'}) để xem quyền đó có yêu cầu cử chỉ của người dùng hay có thể được cấp tự động.
Nếu quyền là granted, bạn có thể gọi document.requestStorageAccess() và thao tác này sẽ thành công mà không cần cử chỉ của người dùng.
Nếu trạng thái quyền là prompt, bạn cần bắt đầu lệnh gọi document.requestStorageAccess() sau một cử chỉ của người dùng, chẳng hạn như khi người dùng nhấp vào nút.
Ví dụ:
navigator.permissions.query({name: 'storage-access'}).then(res => {
if (res.state === 'granted') {
// Permission has already been granted
// You can request storage access without any user gesture
rSA();
} else if (res.state === 'prompt') {
// Requesting storage access requires user gesture
// For example, clicking a button
const btn = document.createElement("button");
btn.textContent = "Grant access";
btn.addEventListener('click', () => {
// Request storage access
rSA();
});
document.body.appendChild(btn);
}
});
function rSA() {
if ('requestStorageAccess' in document) {
document.requestStorageAccess().then(
(res) => {
// Use storage access
},
(err) => {
// Handle errors
}
);
}
}
Các yêu cầu tiếp theo từ trong khung, hoạt động điều hướng hoặc tài nguyên phụ sẽ tự động có quyền truy cập vào cookie trên nhiều trang web.
hasStorageAccess() trả về giá trị true và cookie trên nhiều trang web từ cùng một Nhóm trang web có liên quan sẽ được gửi theo các yêu cầu đó mà không cần thêm lệnh gọi JavaScript nào.
Các trang web cấp cao nhất yêu cầu quyền truy cập vào cookie thay cho các trang web trên nhiều nguồn
requestStorageAccessFor() trên một trang web cấp cao nhất cho một nguồn gốc khácCác trang web cấp cao nhất có thể sử dụng requestStorageAccessFor() để yêu cầu quyền truy cập vào bộ nhớ thay cho những nguồn gốc cụ thể.
hasStorageAccess() chỉ kiểm tra xem trang web gọi nó có quyền truy cập vào bộ nhớ hay không, vì vậy, một trang web cấp cao nhất có thể kiểm tra các quyền cho một nguồn gốc khác.
Để biết liệu người dùng có được nhắc hay không hoặc liệu quyền truy cập vào bộ nhớ đã được cấp cho nguồn gốc cụ thể hay chưa, hãy gọi navigator.permissions.query({name:
'top-level-storage-access', requestedOrigin: 'https://target.site'}).
Nếu quyền là granted, bạn có thể gọi document.requestStorageAccessFor('https://target.site'). Thao tác này sẽ thành công mà không cần cử chỉ của người dùng.
Nếu quyền là prompt, thì bạn sẽ cần liên kết lệnh gọi document.requestStorageAccessFor('https://target.site') sau cử chỉ của người dùng, chẳng hạn như một lượt nhấp vào nút.
Ví dụ:
navigator.permissions.query({name:'top-level-storage-access',requestedOrigin: 'https://target.site'}).then(res => {
if (res.state === 'granted') {
// Permission has already been granted
// You can request storage access without any user gesture
rSAFor();
} else if (res.state === 'prompt') {
// Requesting storage access requires user gesture
// For example, clicking a button
const btn = document.createElement("button");
btn.textContent = "Grant access";
btn.addEventListener('click', () => {
// Request storage access
rSAFor();
});
document.body.appendChild(btn);
}
});
function rSAFor() {
if ('requestStorageAccessFor' in document) {
document.requestStorageAccessFor().then(
(res) => {
// Use storage access
},
(err) => {
// Handle errors
}
);
}
}
Sau khi lệnh gọi requestStorageAccessFor() thành công, các yêu cầu trên nhiều trang web sẽ bao gồm cookie nếu chúng bao gồm CORS hoặc thuộc tính crossorigin, vì vậy, các trang web có thể muốn đợi trước khi kích hoạt một yêu cầu.
Các yêu cầu phải sử dụng lựa chọn credentials: 'include' và tài nguyên phải có thuộc tính crossorigin="use-credentials".
function checkCookie() {
fetch('https://related-website-sets.glitch.me/getcookies.json', {
method: 'GET',
credentials: 'include'
})
.then((response) => response.json())
.then((json) => {
// Do something
});
}
Cách kiểm thử cục bộ
Điều kiện tiên quyết
Để kiểm thử Nhóm trang web có liên quan cục bộ, hãy dùng Chrome 119 trở lên được khởi chạy từ dòng lệnh và bật test-third-party-cookie-phaseout cờ Chrome.
Bật cờ Chrome
Để bật cờ Chrome cần thiết, hãy chuyển đến chrome://flags#test-third-party-cookie-phaseout trên thanh địa chỉ và thay đổi cờ thành Enabled. Đừng quên khởi động lại trình duyệt sau khi thay đổi cờ.
Chạy Chrome bằng Bộ trang web có liên quan cục bộ
Để chạy Chrome bằng Nhóm trang web có liên quan được khai báo cục bộ, hãy tạo một đối tượng JSON chứa các URL là thành viên của một nhóm và truyền đối tượng đó đến --use-related-website-set.
Tìm hiểu thêm về cách chạy Chromium bằng các cờ.
--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/
Ví dụ:
Để bật Nhóm trang web có liên quan cục bộ, bạn cần bật test-third-party-cookie-phaseout trong chrome://flags và khởi chạy Chrome từ dòng lệnh bằng cờ --use-related-website-set với đối tượng JSON chứa các URL là thành viên của một nhóm.
--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/
Xác minh rằng bạn có quyền truy cập vào cookie trên nhiều trang web
Gọi các API (rSA hoặc rSAFor) từ những trang web đang được kiểm thử và xác thực quyền truy cập vào cookie trên nhiều trang web.
Quy trình gửi Bộ trang web có liên quan
Hãy thực hiện các bước sau để khai báo mối quan hệ giữa các miền và chỉ định miền nào thuộc miền con nào.
1. Xác định RWS của bạn
Xác định các miền có liên quan, bao gồm cả set primary và set members sẽ thuộc Bộ trang web có liên quan. Đồng thời xác định loại tập hợp con mà mỗi thành viên của tập hợp thuộc về.
2. Tạo yêu cầu gửi RWS
Tạo một bản sao cục bộ (sao chép hoặc phân nhánh) của kho lưu trữ GitHub. Trong một nhánh mới, hãy thực hiện các thay đổi đối với tệp related_website_sets.JSON để phản ánh bộ của bạn. Để đảm bảo bộ của bạn có cấu trúc và định dạng JSON phù hợp, bạn có thể sử dụng Công cụ tạo JSON.
3. Đảm bảo RWS của bạn đáp ứng các yêu cầu về kỹ thuật
Đảm bảo bạn đáp ứng các yêu cầu về việc tạo bộ và các yêu cầu về việc xác thực bộ.
4. Kiểm thử RWS cục bộ
Trước khi tạo yêu cầu kéo (PR) để gửi bộ dữ liệu, hãy kiểm thử bản gửi cục bộ để đảm bảo rằng bản gửi đó vượt qua tất cả các bước kiểm tra bắt buộc.
5. Gửi RWS
Gửi Bộ trang web có liên quan bằng cách tạo một PR cho tệp related_website_sets.JSON, nơi Chrome lưu trữ danh sách Bộ trang web có liên quan chính tắc. (Bạn cần có tài khoản GitHub để tạo yêu cầu kéo và bạn sẽ cần ký Thoả thuận cấp phép của người đóng góp (CLA) trước khi có thể đóng góp cho danh sách.)
Sau khi PR được tạo, một loạt các bước kiểm tra sẽ được hoàn tất để đảm bảo rằng các yêu cầu ở bước 3 đã được thực hiện, chẳng hạn như đảm bảo rằng bạn đã ký CLA và tệp .well-known hợp lệ.
Nếu thành công, yêu cầu kéo sẽ cho biết các bước kiểm tra đã được thực hiện. Các yêu cầu kéo được phê duyệt sẽ được hợp nhất theo cách thủ công theo đợt vào danh sách Bộ trang web có liên quan chính tắc mỗi tuần một lần (vào lúc 12 giờ trưa thứ Ba theo giờ Miền Đông). Nếu có bất kỳ quy trình kiểm tra nào không thành công, người gửi sẽ nhận được thông báo qua lỗi PR trên GitHub. Người gửi có thể sửa lỗi và cập nhật yêu cầu kéo, đồng thời lưu ý rằng:
- Nếu PR không thành công, thông báo lỗi sẽ cung cấp thêm thông tin về lý do khiến việc gửi có thể không thành công. (ví dụ).
- Tất cả các quy trình kiểm tra kỹ thuật chi phối việc gửi bộ đều được thực hiện trên GitHub. Do đó, tất cả các trường hợp gửi không thành công do quy trình kiểm tra kỹ thuật đều có thể xem được trên GitHub.
Chính sách doanh nghiệp
Chrome có hai chính sách để đáp ứng nhu cầu của người dùng doanh nghiệp:
- Những hệ thống có thể không tích hợp được với Nhóm trang web có liên quan có thể tắt tính năng Nhóm trang web có liên quan trong tất cả các phiên bản Chrome dành cho doanh nghiệp bằng chính sách
RelatedWebsiteSetsEnabled.- Một số hệ thống doanh nghiệp có các trang web chỉ dành cho nội bộ (chẳng hạn như mạng nội bộ) với các miền có thể đăng ký khác với các miền trong Bộ trang web có liên quan. Nếu cần xử lý các trang web này như một phần của Bộ trang web có liên quan mà không công khai (vì các miền có thể là thông tin mật), họ có thể tăng cường hoặc ghi đè danh sách Bộ trang web có liên quan công khai bằng chính sách
RelatedWebsiteSetsOverrides.
- Một số hệ thống doanh nghiệp có các trang web chỉ dành cho nội bộ (chẳng hạn như mạng nội bộ) với các miền có thể đăng ký khác với các miền trong Bộ trang web có liên quan. Nếu cần xử lý các trang web này như một phần của Bộ trang web có liên quan mà không công khai (vì các miền có thể là thông tin mật), họ có thể tăng cường hoặc ghi đè danh sách Bộ trang web có liên quan công khai bằng chính sách
Chrome sẽ giải quyết mọi điểm giao nhau giữa các tập hợp công khai và tập hợp dành cho doanh nghiệp theo một trong hai cách, tuỳ thuộc vào việc bạn chỉ định replacements hay additions.
Ví dụ: đối với tập hợp công khai {primary: A, associated: [B, C]}:
Séc replacements: |
{primary: C, associated: [D, E]} |
| Tập hợp doanh nghiệp hấp thụ trang web chung để tạo thành một tập hợp mới. | |
| Các tập hợp thu được: | {primary: A, associated: [B]}{primary: C, associated: [D, E]} |
Séc additions: |
{primary: C, associated: [D, E]} |
| Các tập hợp Công khai và Doanh nghiệp được kết hợp. | |
| Tập hợp thu được: | {primary: C, associated: [A, B, D, E]} |
Khắc phục sự cố liên quan đến Bộ trang web có liên quan
"Lời nhắc người dùng" và "cử chỉ của người dùng"
"Lời nhắc cho người dùng" và "cử chỉ của người dùng" là hai khái niệm khác nhau. Chrome sẽ không hiển thị lời nhắc cấp quyền cho người dùng đối với những trang web nằm trong cùng một Nhóm trang web có liên quan, nhưng Chrome vẫn yêu cầu người dùng đã tương tác với trang. Trước khi cấp quyền, Chrome yêu cầu phải có một cử chỉ của người dùng, còn được gọi là "tương tác của người dùng" hoặc "kích hoạt của người dùng". Điều này là do việc sử dụng Storage Access API bên ngoài bối cảnh Bộ trang web có liên quan (cụ thể là requestStorageAccess()) cũng yêu cầu cử chỉ của người dùng, do các nguyên tắc thiết kế nền tảng web.
Truy cập vào cookie hoặc bộ nhớ của các trang web khác
Bộ trang web có liên quan không hợp nhất bộ nhớ cho các trang web khác nhau: bộ nhớ này chỉ cho phép các lệnh gọi requestStorageAccess() dễ dàng hơn (không có lời nhắc). Bộ trang web có liên quan chỉ làm giảm sự khó chịu của người dùng khi sử dụng Storage Access API, nhưng không quy định những việc cần làm sau khi quyền truy cập được khôi phục. Nếu A và B là các trang web khác nhau trong cùng một Bộ trang web có liên quan và A nhúng B, thì B có thể gọi requestStorageAccess() và có quyền truy cập vào bộ nhớ của bên thứ nhất mà không cần nhắc người dùng. Bộ trang web có liên quan không thực hiện bất kỳ hoạt động giao tiếp nào trên nhiều trang web. Ví dụ: việc thiết lập một Bộ trang web có liên quan sẽ không khiến cookie thuộc về B bắt đầu được gửi đến A. Nếu muốn chia sẻ dữ liệu đó, bạn sẽ phải tự chia sẻ, chẳng hạn như bằng cách gửi một window.postMessage từ iframe B đến khung A.
Theo mặc định, quyền truy cập vào cookie không được phân vùng
Bộ trang web có liên quan không cho phép truy cập ngầm vào cookie chưa được phân vùng mà không cần gọi bất kỳ API nào. Theo mặc định, cookie trên nhiều trang web sẽ không có sẵn trong nhóm; Bộ trang web có liên quan chỉ cho phép các trang web trong nhóm bỏ qua lời nhắc cấp quyền Storage Access API.
Iframe phải gọi document.requestStorageAccess() nếu muốn truy cập vào cookie của mình hoặc trang cấp cao nhất có thể gọi document.requestStorageAccessFor().
Chia sẻ ý kiến phản hồi
Gửi một tập hợp trên GitHub và làm việc với Storage Access API và requestStorageAccessFor API là cơ hội để chia sẻ trải nghiệm của bạn về quy trình và mọi vấn đề bạn gặp phải.
Cách tham gia thảo luận về Bộ trang web có liên quan:
- Tham gia danh sách gửi thư công khai của Nhóm trang web có liên quan.
- Nêu vấn đề và theo dõi cuộc thảo luận trên kho lưu trữ Bộ trang web có liên quan trên GitHub.