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 tập hợp các 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 nhất định 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.
Khi Chrome ngừng sử dụng cookie của bên thứ ba, mục tiêu của Chrome là duy trì các trường hợp sử dụng chính trên web trong khi vẫn cải thiện quyền riêng tư cho người dùng. Ví dụ: nhiều trang web dựa vào nhiều miền để phân phát một trải nghiệm người dùng. 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 quốc gia hoặc miền dịch vụ để lưu trữ hình ảnh hoặc video. Nhóm trang web có liên quan cho phép các trang web chia sẻ dữ liệu trên các miền, với các chế độ kiểm soát cụ thể.
Bộ trang web có liên quan là gì?
Nói chung, Bộ trang web có liên quan là một tập hợp các miền, trong đó có một "miền chính" và có thể có nhiều "thành viên trong bộ".
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 nhóm con được liên kết.
{
"primary": "https://primary.com",
"associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}
Danh sách chính tắc của Nhóm trang web có liên quan là danh sách có thể xem công khai ở định dạng tệp JSON được lưu trữ trong Kho lưu trữ GitHub của Nhóm trang web có liên quan. Danh sách này đóng vai trò là nguồn đáng tin cậy cho tất cả các nhóm. Chrome sử dụng tệp này để áp dụng cho hành vi của nó.
Chỉ những người có quyền quản trị đối với một miền mới có thể tạo tập hợp bằng miền đó. Người gửi bắt buộc phải khai báo mối quan hệ giữa mỗi "thành phần tập hợp" với "thành phần tập hợp chính". Các thành phần của tập hợp có thể bao gồm nhiều loại miền và phải thuộc một nhóm con dựa trên 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 API Truy cập bộ nhớ (SAA) và API requestStorageAccessFor để yêu cầu quyền truy cập vào các 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 nhau.
Để tìm hiểu thêm về quy trình và các yêu cầu đối với việc gửi bộ sách, hãy xem nguyên tắc gửi. Các tập hợp đã 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. Tận dụng các trang web đã bản địa hoá trong khi vẫn dựa vào cơ sở hạ tầng dùng chung (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ờ trực tiếp tương tác, nhưng cung cấp dịch vụ trên các trang web của cùng một tổ chức (example-cdn.com).
- Tách nội dung của người dùng. Truy cập dữ liệu trên các miền khác nhau để tách nội dung do người dùng tải lên khỏ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 hộp cát 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 do người dùng tải lên nhưng không còn hoạt động, 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 được 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 tính nă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
API truy cập bộ nhớ (SAA) cung cấp một cách để nội dung được nhúng trên nhiều nguồn gốc truy cập vào bộ nhớ mà nội dung đó thường chỉ có thể truy cập trong ngữ 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 chúng hiện 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 Nhóm trang web có liên quan (RWS) được bật, Chrome sẽ tự động cấp quyền trong ngữ cảnh nội bộ của RWS và sẽ hiển thị lời nhắc cho người dùng nếu không. ("Ngữ cảnh trong RWS" là một ngữ cảnh, chẳng hạn như iframe, trong đó 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 chúng hiện có quyền truy cập vào bộ nhớ hay không, các trang web được nhúng có thể sử 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 hay chưa. Lời hứa cũng trả về 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 trên 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ả 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ẽ phân giải nếu quyền truy cập vào bộ nhớ được cấp. Lời hứa sẽ bị từ chối, kèm theo lý do, nếu quyền truy cập bị từ chối vì bất kỳ lý do gì.
requestStorageAccessFor trong Chrome
API Truy cập bộ nhớ chỉ cho phép các trang web được nhúng yêu cầu quyền truy cập vào bộ nhớ từ bên trong các phần tử <iframe>
đã nhận được hoạt động tương tác của người dùng.
Điều này gây ra thách thức trong việc áp dụng API Truy cập bộ nhớ cho các trang web cấp cao nhất sử dụng hình ảnh trên nhiều trang web hoặc thẻ tập lệnh 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 thay mặt cho các nguồn gốc cụ thể yêu cầu quyền truy cập vào bộ nhớ 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 hoạt động tương tác trong tài liệu cấp cao nhất trong vòng 30 ngày qua 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ư máy ảnh hoặc vị trí địa lý, 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 – cho dù 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 navigator.permissions.query()
.
Để kiểm tra quyền truy cập bộ nhớ cho ngữ cảnh hiện tại, bạn cần truyền chuỗi 'storage-access'
:
navigator.permissions.query({name: 'storage-access'})
Để kiểm tra quyền truy cập 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, phương thức này chỉ kiểm tra các quyền do tài liệu cấp cao nhất cấp bằng document.requestStorageAccessFor
.
Tuỳ thuộc vào việc quyền có thể được cấp tự động hay cần có cử chỉ của người dùng, quyền này sẽ trả về prompt
hoặc granted
.
Mô hình theo khung hình
Quyền cấp rSA áp dụng cho mỗi khung. Quyền cấp rSA và rSAFor được coi là các quyền riêng biệt.
Mỗi khung mới sẽ cần yêu cầu quyền truy cập vào bộ nhớ riêng lẻ và sẽ tự động được cấp quyền truy cập. Chỉ yêu cầu đầu tiên mới yêu cầu 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 phải chờ 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.
Bạn sẽ phải yêu cầu cấp quyền truy cập lại nếu làm mới, tải lại hoặc tạo lại iframe.
Yêu cầu về cookie
Cookie phải chỉ định cả thuộc tính SameSite=None
và Secure
vì rSA chỉ cung cấp quyền truy cập cho những cookie đã được đánh dấu để sử dụng trong ngữ cảnh trên nhiều trang web.
Cookie có thuộc tính SameSite=Lax
, SameSite=Strict
hoặc không có thuộc tính SameSite
chỉ dành cho 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 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 bạn 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 trên nhiều nguồn gốc được nhúng

requestStorageAccess()
trong một 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 đúng, bạn có thể truy cập vào bộ nhớ trong ngữ cảnh trên nhiều trang web. Nếu giá trị này là sai, 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 hay khô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 khi người dùng thực hiện một cử chỉ, chẳng hạn như 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, thao tác đ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 trên các yêu cầu đó mà không cần thêm lệnh gọi JavaScript nào.
Trang web cấp cao nhất yêu cầu quyền truy cập cookie thay mặt cho các trang web trên nhiều nguồn gốc

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()
để thay mặt cho các nguồn gốc cụ thể yêu cầu quyền truy cập vào bộ nhớ.
hasStorageAccess()
chỉ kiểm tra xem trang web gọi phương thức này 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 quyền cho một nguồn gốc khác.
Để tìm hiểu xem người dùng có được nhắc hay không hoặc quyền truy cập vào bộ nhớ đã được cấp cho nguồn gốc đã chỉ định 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 thao tác của người dùng.
Nếu quyền là prompt
, thì bạn sẽ cần nối 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 các yêu cầu đó 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 yêu cầu.
Các yêu cầu phải sử dụng tuỳ chọn credentials: 'include'
và tài nguyên phải bao gồm 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ử các Nhóm trang web có liên quan trên máy, hãy sử dụng Chrome 119 trở lên được chạy từ dòng lệnh và bật cờ Chrome test-third-party-cookie-phaseout
.
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ỉ rồi thay đổi cờ thành Enabled
. Hãy nhớ khởi động lại trình duyệt sau khi thay đổi cờ.
Chạy Chrome bằng một Tập hợp trang web có liên quan cục bộ
Để khởi chạy Chrome bằng Tập hợp 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 tập hợp 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ờ.
--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 Tập hợp trang web có liên quan trên máy, 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 tập hợp.
--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ừ các 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 làm theo các bước sau để khai báo mối quan hệ giữa các miền và chỉ định tập hợp con mà các miền đó thuộc về.
1. Xác định RWS
Xác định các miền có liên quan, bao gồm cả miền chính của nhóm và các miền thành viên của nhóm sẽ thuộc Bộ trang web có liên quan. Ngoài ra, hãy xác định loại tập hợp con mà mỗi thành phần của tập hợp thuộc về.
2. Tạo nội dung gửi cho 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 tập hợp của bạn. Để đảm bảo tập hợp của bạn có định dạng và cấu trúc JSON phù hợp, bạn có thể sử dụng Công cụ tạo JSON.
3. Đảm bảo rằng RWS của bạn đáp ứng các yêu cầu kỹ thuật
Đảm bảo rằng bạn đã thực hiện các yêu cầu về việc tạo nhóm và các yêu cầu về việc xác thực nhóm.
4. Kiểm thử RWS cục bộ
Trước khi tạo yêu cầu kéo (PR) để gửi tập hợp, hãy kiểm thử nội dung bạn gửi trên máy để đảm bảo rằng nội dung đó 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 bản PR cho tệp related_website_sets.JSON nơi Chrome lưu trữ danh sách Bộ trang web có liên quan chuẩn hoá. (Bạn cần có tài khoản GitHub để tạo yêu cầu thay đổi và bạn sẽ cần ký Thoả thuận cấp phép của cộng tác viên (CLA) trước khi có thể đóng góp vào danh sách.)
Sau khi tạo yêu cầu thay đổi, một loạt các bước kiểm tra sẽ được hoàn tất để đảm bảo rằng bạn đã đáp ứng các yêu cầu ở bước 3, chẳng hạn như đảm bảo rằng bạn đã ký CLA và tệp .well-known
là hợp lệ.
Nếu thành công, PR sẽ cho biết rằng các bước kiểm tra đã hoàn tất. Các yêu cầu thay đổi đối với trang web đã được phê duyệt sẽ được hợp nhất theo lô theo cách thủ công vào danh sách Bộ trang web có liên quan chính tắc một lần mỗi tuần (vào lúc 12 giờ trưa 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 về lỗi thông báo báo chí trên GitHub. Người gửi có thể sửa lỗi và cập nhật yêu cầu thay đổi mã nguồn. Xin lưu ý rằng:
- Nếu không gửi được thông tin xác nhận quyền sở hữu, bạn sẽ thấy một thông báo lỗi cung cấp thêm thông tin về lý do có thể khiến thông tin xác nhận quyền sở hữu không được gửi. (ví dụ).
- Tất cả các quy trình kiểm tra kỹ thuật quản lý việc gửi bộ bài đều được thực hiện trên GitHub. Do đó, tất cả các lần 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 dành cho 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 Tập hợp trang web có liên quan. Nếu cần coi những trang web này là một phần của Bộ trang web có liên quan mà không công khai các trang web đó (vì các miền có thể là thông tin bảo mật), thì họ có thể bổ sung hoặc ghi đè danh sách Bộ trang web có liên quan công khai bằng chính sách
RelatedWebsiteSetsOverrides
.
Chrome phân giải mọi giao điểm của tập hợp công khai và tập hợp Doanh nghiệp theo một trong hai cách, tuỳ thuộc vào việc bạn chỉ định replacemements
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 sẽ hấp thụ trang web chung để tạo thành một tập hợp mới. | |
Tập hợp kết quả: | {primary: A, associated: [B]} {primary: C, associated: [D, E]} |
Séc additions : |
{primary: C, associated: [D, E]} |
Các nhóm Công khai và Doanh nghiệp được kết hợp. | |
Tập hợp kết quả: | {primary: C, associated: [A, B, D, E]} |
Khắc phục sự cố về 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 người dùng" và "cử chỉ 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 các trang web thuộc 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 một cử chỉ của người dùng, còn 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". Lý do là việc sử dụng API Truy cập bộ nhớ bên ngoài ngữ cảnh của Nhóm trang web có liên quan (cụ thể là requestStorageAccess()
) cũng yêu cầu một cử chỉ của người dùng, do 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
Nhóm trang web có liên quan không hợp nhất bộ nhớ cho các trang web khác nhau: nhóm 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). Nhóm trang web liên quan chỉ làm giảm sự phiền hà của người dùng khi sử dụng API quyền truy cập vào bộ nhớ, nhưng không chỉ định việc cần làm sau khi khôi phục quyền truy cập. Nếu A và B là các trang web khác nhau trong cùng một Nhóm 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 Nhóm 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 window.postMessage
từ một iframe B đến một khung A.
Quyền truy cập cookie không phân vùng theo mặc định
Nhóm trang web có liên quan không cho phép truy cập cookie không phân vùng ngầm ẩn mà không gọi bất kỳ API nào. Theo mặc định, cookie trên nhiều trang web sẽ không được cung cấp trong tập hợp; Tập hợp trang web có liên quan chỉ cho phép các trang web trong tập hợp bỏ qua lời nhắc cấp quyền API Truy cập bộ nhớ.
Iframe phải gọi document.requestStorageAccess()
nếu muốn truy cập vào cookie hoặc trang cấp cao nhất có thể gọi document.requestStorageAccessFor()
.
Chia sẻ ý kiến phản hồi
Việc gửi một tập hợp trên GitHub và làm việc với API Truy cập bộ nhớ và API requestStorageAccessFor
là cơ hội để bạn chia sẻ trải nghiệm của mình về quy trình này 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 về Bộ trang web có liên quan.
- Đưa ra vấn đề và theo dõi cuộc thảo luận trên Kho lưu trữ GitHub của Nhóm trang web có liên quan.