রিলেটেড ওয়েবসাইট সেট (RWS) হল একটি ওয়েব প্ল্যাটফর্ম প্রক্রিয়া যা ব্রাউজারগুলিকে ডোমেনের একটি সংগ্রহের মধ্যে সম্পর্ক বুঝতে সাহায্য করে। এটি ব্রাউজারগুলিকে নির্দিষ্ট সাইট ফাংশনগুলি সক্ষম করার জন্য (যেমন ক্রস-সাইট কুকিগুলিতে অ্যাক্সেসের অনুমতি দেওয়া হবে কিনা) এবং ব্যবহারকারীদের কাছে এই তথ্য উপস্থাপন করার জন্য গুরুত্বপূর্ণ সিদ্ধান্ত নিতে দেয়।
অনেক সাইট একক ব্যবহারকারীর অভিজ্ঞতা প্রদানের জন্য একাধিক ডোমেনের উপর নির্ভর করে। প্রতিষ্ঠানগুলি একাধিক ব্যবহারের ক্ষেত্রে বিভিন্ন শীর্ষ-স্তরের ডোমেন বজায় রাখতে চাইতে পারে, যেমন দেশ-নির্দিষ্ট ডোমেন বা ছবি বা ভিডিও হোস্ট করার জন্য পরিষেবা ডোমেন। সম্পর্কিত ওয়েবসাইট সেটগুলি সাইটগুলিকে নির্দিষ্ট নিয়ন্ত্রণ সহ ডোমেন জুড়ে ডেটা ভাগ করে নেওয়ার অনুমতি দেয়।
একটি সম্পর্কিত ওয়েবসাইট সেট কি?
উচ্চ স্তরে, একটি সম্পর্কিত ওয়েবসাইট সেট হল ডোমেনের একটি সংগ্রহ, যার জন্য একটি একক "প্রাথমিক সেট" এবং সম্ভাব্য একাধিক "সেট সদস্য" থাকে।
নিম্নলিখিত উদাহরণে, primary প্রাথমিক ডোমেন তালিকাভুক্ত করে, এবং associatedSites এমন ডোমেন তালিকাভুক্ত করে যা সংশ্লিষ্ট সাবসেটের প্রয়োজনীয়তা পূরণ করে।
{
"primary": "https://primary.com",
"associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}
সম্পর্কিত ওয়েবসাইট সেটগুলি GitHub-এ হোস্ট করা একটি পাবলিক JSON ফাইলে তালিকাভুক্ত করা হয়। এটি সমস্ত অনুমোদিত সেটের জন্য ক্যানোনিকাল উৎস। ব্রাউজারগুলি এই ফাইলটি ব্যবহার করে নির্ধারণ করে যে সাইটগুলি একই সম্পর্কিত ওয়েবসাইট সেটের অন্তর্গত কিনা।
শুধুমাত্র যাদের ডোমেনের উপর প্রশাসনিক নিয়ন্ত্রণ আছে তারাই সেই ডোমেনের সাথে একটি সেট তৈরি করতে পারে। জমাদাতাদের প্রতিটি "সেট সদস্য" এর "সেট প্রাথমিক" এর সাথে সম্পর্ক ঘোষণা করতে হবে। সেট সদস্যদের বিভিন্ন ধরণের ডোমেন অন্তর্ভুক্ত থাকতে পারে এবং ব্যবহারের ক্ষেত্রের উপর ভিত্তি করে একটি উপসেটের অংশ হতে হবে।
যদি আপনার অ্যাপ্লিকেশনটি একই সম্পর্কিত ওয়েবসাইট সেটের মধ্যে থাকা সাইটগুলিতে ক্রস-সাইট কুকিজ (যাকে তৃতীয় পক্ষের কুকিজও বলা হয়) অ্যাক্সেসের উপর নির্ভর করে, তাহলে আপনি সেই কুকিগুলিতে অ্যাক্সেসের অনুরোধ করতে স্টোরেজ অ্যাক্সেস API (SAA) এবং requestStorageAccessFor API ব্যবহার করতে পারেন। প্রতিটি সাইট কোন সাবসেটের অংশ তার উপর নির্ভর করে, ব্রাউজারটি অনুরোধটি ভিন্নভাবে পরিচালনা করতে পারে।
সেট জমা দেওয়ার প্রক্রিয়া এবং প্রয়োজনীয়তা সম্পর্কে আরও জানতে, জমা দেওয়ার নির্দেশিকাগুলি দেখুন। জমা দেওয়া সেটগুলি জমা দেওয়ার বৈধতা যাচাই করার জন্য বিভিন্ন প্রযুক্তিগত পরীক্ষার মধ্য দিয়ে যাবে।
সম্পর্কিত ওয়েবসাইট সেট ব্যবহারের ক্ষেত্রে
যখন কোনও প্রতিষ্ঠানের বিভিন্ন শীর্ষ-স্তরের সাইট জুড়ে ভাগ করা পরিচয়ের একটি ফর্মের প্রয়োজন হয়, তখন সম্পর্কিত ওয়েবসাইট সেটগুলি তাদের জন্য উপযুক্ত।
সম্পর্কিত ওয়েবসাইট সেটের জন্য কিছু ব্যবহারের উদাহরণ হল:
- দেশ কাস্টমাইজেশন । শেয়ার্ড অবকাঠামোর উপর নির্ভর করে স্থানীয় সাইটগুলিকে কাজে লাগানো (example.co.uk example.ca দ্বারা হোস্ট করা কোনও পরিষেবার উপর নির্ভর করতে পারে)।
- পরিষেবা ডোমেন ইন্টিগ্রেশন । এমন পরিষেবা ডোমেন ব্যবহার করা যার সাথে ব্যবহারকারীরা কখনও সরাসরি যোগাযোগ করে না, কিন্তু একই সংস্থার সাইটগুলিতে পরিষেবা প্রদান করে (example-cdn.com)।
- ব্যবহারকারীর কন্টেন্ট পৃথকীকরণ । নিরাপত্তার কারণে ব্যবহারকারীর আপলোড করা কন্টেন্টকে অন্য সাইটের কন্টেন্ট থেকে আলাদা করে এমন বিভিন্ন ডোমেনের ডেটা অ্যাক্সেস করা, একই সাথে স্যান্ডবক্সযুক্ত ডোমেনকে প্রমাণীকরণ (এবং অন্যান্য) কুকিতে অ্যাক্সেস দেওয়ার অনুমতি দেওয়া। যদি আপনি নিষ্ক্রিয় ব্যবহারকারীর আপলোড করা কন্টেন্ট পরিবেশন করেন, তাহলে আপনি সর্বোত্তম অনুশীলন অনুসরণ করে একই ডোমেনে নিরাপদে এটি হোস্ট করতে সক্ষম হতে পারেন।
- এম্বেডেড প্রমাণীকৃত কন্টেন্ট । অনুমোদিত সম্পত্তি (ভিডিও, ডকুমেন্ট, অথবা শীর্ষ-স্তরের সাইটে সাইন ইন করা ব্যবহারকারীর মধ্যে সীমাবদ্ধ রিসোর্স) থেকে এম্বেডেড কন্টেন্ট সমর্থন করে।
- সাইন-ইন । অনুমোদিত সম্পত্তি জুড়ে সাইন-ইন সমর্থন করে। FedCM API কিছু ব্যবহারের ক্ষেত্রেও উপযুক্ত হতে পারে।
- অ্যানালিটিক্স । পরিষেবার মান উন্নত করার জন্য অনুমোদিত সম্পত্তি জুড়ে বিশ্লেষণ স্থাপন এবং ব্যবহারকারীর ভ্রমণের পরিমাপ।
সম্পর্কিত ওয়েবসাইট ইন্টিগ্রেশনের বিবরণ সেট করে
স্টোরেজ অ্যাক্সেস API
স্টোরেজ অ্যাক্সেস API (SAA) এমবেডেড ক্রস-অরিজিন কন্টেন্টকে স্টোরেজ অ্যাক্সেস করার একটি উপায় প্রদান করে যা সাধারণত শুধুমাত্র প্রথম-পক্ষের প্রসঙ্গে অ্যাক্সেস থাকে।
এমবেডেড রিসোর্সগুলি SAA পদ্ধতি ব্যবহার করে তাদের বর্তমানে স্টোরেজ অ্যাক্সেস আছে কিনা তা পরীক্ষা করতে এবং ব্যবহারকারী এজেন্টের কাছ থেকে অ্যাক্সেসের অনুরোধ করতে পারে।
যখন থার্ড-পার্টি কুকিজ ব্লক করা থাকে কিন্তু রিলেটেড ওয়েবসাইট সেট (RWS) সক্রিয় থাকে, তখন Chrome স্বয়ংক্রিয়ভাবে ইন্ট্রা-RWS প্রসঙ্গে অনুমতি দেবে এবং অন্যথায় ব্যবহারকারীকে একটি প্রম্পট দেখাবে। ("ইন্ট্রা-RWS প্রসঙ্গে" হল একটি প্রসঙ্গের মতো, যেমন একটি আইফ্রেম, যার এমবেডেড সাইট এবং টপ-লেভেল সাইট একই RWS-এ থাকে।)
স্টোরেজ অ্যাক্সেস পরীক্ষা করে অনুরোধ করুন
এমবেডেড সাইটগুলি বর্তমানে স্টোরেজ অ্যাক্সেস করছে কিনা তা পরীক্ষা করার জন্য, Document.hasStorageAccess() পদ্ধতি ব্যবহার করতে পারে।
এই পদ্ধতিটি একটি প্রতিশ্রুতি প্রদান করে যা একটি বুলিয়ান মান সহ সমাধান করে যা নির্দেশ করে যে ডকুমেন্টটির ইতিমধ্যেই তার কুকিতে অ্যাক্সেস আছে কিনা। যদি আইফ্রেমটি উপরের ফ্রেমের মতো একই-অরিজিন হয় তবে প্রতিশ্রুতিটি সত্যও প্রদান করে।
ক্রস-সাইট প্রসঙ্গে কুকিজ অ্যাক্সেসের অনুরোধ করতে, এমবেডেড সাইটগুলি Document.requestStorageAccess() (rSA) ব্যবহার করতে পারে।
requestStorageAccess() API একটি iframe এর ভেতর থেকে কল করার জন্য তৈরি। সেই iframe-কে অবশ্যই ব্যবহারকারীর ইন্টারঅ্যাকশন (একটি ব্যবহারকারীর অঙ্গভঙ্গি , যা সকল ব্রাউজারে প্রয়োজন) গ্রহণ করতে হবে, তবে Chrome অতিরিক্তভাবে দাবি করে যে গত 30 দিনের মধ্যে কোনও এক সময়ে, ব্যবহারকারী সেই iframe-এর মালিকানাধীন সাইটটি পরিদর্শন করেছেন এবং সেই সাইটের সাথে বিশেষভাবে ইন্টারঅ্যাক্ট করেছেন - একটি শীর্ষ-স্তরের ডকুমেন্ট হিসাবে, কোনও iframe-এ নয়।
requestStorageAccess() একটি প্রতিশ্রুতি প্রদান করে যা স্টোরেজ অ্যাক্সেস মঞ্জুর করা হয়েছে কিনা তা সমাধান করে। যদি কোনও কারণে অ্যাক্সেস অস্বীকার করা হয় তবে কারণ উল্লেখ করে প্রতিশ্রুতি প্রত্যাখ্যান করা হয়।
Chrome-এ requestStorageAccessFor
স্টোরেজ অ্যাক্সেস API শুধুমাত্র এমবেডেড সাইটগুলিকে <iframe> এলিমেন্টের মধ্যে থেকে স্টোরেজ অ্যাক্সেসের অনুরোধ করতে দেয় যা ব্যবহারকারীর ইন্টারঅ্যাকশন পেয়েছে।
এটি শীর্ষ-স্তরের সাইটগুলির জন্য স্টোরেজ অ্যাক্সেস API গ্রহণের ক্ষেত্রে চ্যালেঞ্জ তৈরি করে যেগুলি ক্রস-সাইট চিত্র বা স্ক্রিপ্ট ট্যাগ ব্যবহার করে যার জন্য কুকি প্রয়োজন।
এই সমস্যা সমাধানের জন্য, Chrome Document.requestStorageAccessFor() (rSAFor) ব্যবহার করে নির্দিষ্ট উৎসের পক্ষে শীর্ষ-স্তরের সাইটগুলির জন্য স্টোরেজ অ্যাক্সেসের অনুরোধ করার একটি উপায় বাস্তবায়ন করেছে।
document.requestStorageAccessFor('https://target.site')
requestStorageAccessFor() API একটি শীর্ষ-স্তরের ডকুমেন্ট দ্বারা কল করার জন্য তৈরি। সেই ডকুমেন্টটি অবশ্যই ব্যবহারকারীর ইন্টারঅ্যাকশন পেয়েছে। কিন্তু requestStorageAccess() এর বিপরীতে, Chrome গত 30 দিনের মধ্যে একটি শীর্ষ-স্তরের ডকুমেন্টে কোনও ইন্টারঅ্যাকশন পরীক্ষা করে না কারণ ব্যবহারকারী ইতিমধ্যেই পৃষ্ঠায় রয়েছে।
স্টোরেজ অ্যাক্সেসের অনুমতি পরীক্ষা করুন
কিছু ব্রাউজার বৈশিষ্ট্য, যেমন ক্যামেরা বা ভূ-অবস্থান, ব্যবহারকারীর দ্বারা প্রদত্ত অনুমতির উপর ভিত্তি করে অ্যাক্সেস করা হয়। Permissions API একটি API অ্যাক্সেস করার জন্য অনুমতির স্থিতি পরীক্ষা করার একটি উপায় প্রদান করে - এটি মঞ্জুর করা হয়েছে কিনা, অস্বীকার করা হয়েছে কিনা, অথবা এর জন্য কোনও ধরণের ব্যবহারকারীর ইন্টারঅ্যাকশনের প্রয়োজন, যেমন একটি প্রম্পটে ক্লিক করা বা পৃষ্ঠার সাথে ইন্টারঅ্যাক্ট করা।
আপনি navigator.permissions.query() ব্যবহার করে অনুমতির অবস্থা জানতে পারেন।
বর্তমান প্রসঙ্গের জন্য স্টোরেজ অ্যাক্সেসের অনুমতি পরীক্ষা করতে আপনাকে 'storage-access' স্ট্রিংটি পাস করতে হবে:
navigator.permissions.query({name: 'storage-access'})
নির্দিষ্ট অরিজিনের জন্য স্টোরেজ অ্যাক্সেসের অনুমতি পরীক্ষা করতে, আপনাকে 'top-level-storage-access' স্ট্রিংটি প্রবেশ করতে হবে:
navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})
মনে রাখবেন যে এমবেডেড অরিজিনের অখণ্ডতা রক্ষা করার জন্য, এটি শুধুমাত্র document.requestStorageAccessFor ব্যবহার করে শীর্ষ-স্তরের ডকুমেন্ট দ্বারা প্রদত্ত অনুমতিগুলি পরীক্ষা করে।
অনুমতিটি স্বয়ংক্রিয়ভাবে মঞ্জুর করা যেতে পারে নাকি ব্যবহারকারীর অঙ্গভঙ্গির প্রয়োজন তার উপর নির্ভর করে, এটি prompt বা granted ফেরত দেবে।
প্রতি ফ্রেম মডেল
প্রতি ফ্রেমে rSA অনুদান প্রযোজ্য। rSA এবং rSAFor অনুদান পৃথক অনুমতি হিসেবে বিবেচিত হয়।
প্রতিটি নতুন ফ্রেমকে পৃথকভাবে স্টোরেজ অ্যাক্সেসের অনুরোধ করতে হবে এবং এটি স্বয়ংক্রিয়ভাবে অ্যাক্সেস মঞ্জুর করা হবে। শুধুমাত্র প্রথম অনুরোধের জন্য ব্যবহারকারীর অঙ্গভঙ্গি প্রয়োজন, আইফ্রেম দ্বারা শুরু হওয়া পরবর্তী কোনও অনুরোধ, যেমন নেভিগেশন বা সাবরিসোর্সগুলির জন্য ব্যবহারকারীর অঙ্গভঙ্গির জন্য অপেক্ষা করতে হবে না কারণ এটি প্রাথমিক অনুরোধের মাধ্যমে ব্রাউজিং সেশনের জন্য মঞ্জুর করা হবে।
আইফ্রেম রিফ্রেশ, রিলোড, অথবা অন্যথায় পুনরায় তৈরি করার জন্য আবার অ্যাক্সেসের অনুরোধ করতে হবে।
কুকির প্রয়োজনীয়তা
কুকিজকে অবশ্যই SameSite=None এবং Secure উভয় বৈশিষ্ট্যই নির্দিষ্ট করতে হবে কারণ rSA শুধুমাত্র ক্রস-সাইট প্রসঙ্গে ব্যবহারের জন্য চিহ্নিত কুকিগুলির জন্য অ্যাক্সেস প্রদান করে ।
SameSite=Lax , SameSite=Strict , অথবা SameSite অ্যাট্রিবিউট ছাড়া কুকিগুলি শুধুমাত্র প্রথম পক্ষের ব্যবহারের জন্য এবং rSA নির্বিশেষে কখনও ক্রস-সাইট প্রসঙ্গে শেয়ার করা হবে না ।
নিরাপত্তা
rSAFor-এর জন্য, সাবরিসোর্স অনুরোধের জন্য ক্রস-অরিজিন রিসোর্স শেয়ারিং (CORS) হেডার অথবা রিসোর্সে crossorigin অ্যাট্রিবিউট প্রয়োজন, যা স্পষ্ট অপ্ট-ইন নিশ্চিত করে।
বাস্তবায়নের উদাহরণ
একটি এমবেডেড ক্রস-অরিজিন আইফ্রেম থেকে স্টোরেজ অ্যাক্সেসের অনুরোধ করুন

requestStorageAccess() ব্যবহার করা। আপনার স্টোরেজ অ্যাক্সেস আছে কিনা তা পরীক্ষা করুন
আপনার কাছে ইতিমধ্যেই স্টোরেজ অ্যাক্সেস আছে কিনা তা পরীক্ষা করতে document.hasStorageAccess() ব্যবহার করুন।
যদি প্রতিশ্রুতিটি সত্য হয়, তাহলে আপনি ক্রস-সাইট প্রসঙ্গে স্টোরেজ অ্যাক্সেস করতে পারবেন। যদি এটি মিথ্যা সমাধান হয়, তাহলে আপনাকে স্টোরেজ অ্যাক্সেসের অনুরোধ করতে হবে।
document.hasStorageAccess().then((hasAccess) => {
if (hasAccess) {
// You can access storage in this context
} else {
// You have to request storage access
}
});
স্টোরেজ অ্যাক্সেসের অনুরোধ করুন
যদি আপনার স্টোরেজ অ্যাক্সেসের অনুরোধ করার প্রয়োজন হয়, তাহলে প্রথমে স্টোরেজ অ্যাক্সেস পারমিশন navigator.permissions.query({name: 'storage-access'}) চেক করে দেখুন যে এর জন্য ব্যবহারকারীর অঙ্গভঙ্গির প্রয়োজন আছে কিনা, নাকি এটি স্বয়ংক্রিয়ভাবে মঞ্জুর করা যেতে পারে।
যদি অনুমতি granted হয়, তাহলে আপনি document.requestStorageAccess() কল করতে পারেন এবং এটি ব্যবহারকারীর কোনও ইঙ্গিত ছাড়াই সফল হবে।
যদি অনুমতির স্থিতি prompt হয়, তাহলে আপনাকে ব্যবহারকারীর অঙ্গভঙ্গির পরে document.requestStorageAccess() কলটি শুরু করতে হবে, যেমন একটি বোতাম ক্লিক।
উদাহরণ:
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
}
);
}
}
ফ্রেমের ভেতর থেকে পরবর্তী অনুরোধ, নেভিগেশন বা সাবরিসোর্সেস, স্বয়ংক্রিয়ভাবে ক্রস-সাইট কুকিজ অ্যাক্সেস করার অনুমতি পাবে। hasStorageAccess() সত্য ফেরত দেয় এবং একই সম্পর্কিত ওয়েবসাইট সেট থেকে ক্রস-সাইট কুকিজ সেই অনুরোধগুলিতে কোনও অতিরিক্ত জাভাস্ক্রিপ্ট কল ছাড়াই পাঠানো হবে।
ক্রস-অরিজিন সাইটের পক্ষ থেকে কুকি অ্যাক্সেসের অনুরোধকারী শীর্ষ-স্তরের সাইটগুলি

requestStorageAccessFor() ব্যবহার করা শীর্ষ-স্তরের সাইটগুলি নির্দিষ্ট উৎসের পক্ষে স্টোরেজ অ্যাক্সেসের অনুরোধ করতে requestStorageAccessFor() ব্যবহার করতে পারে।
hasStorageAccess() শুধুমাত্র যে সাইটটিকে কল করছে তার স্টোরেজ অ্যাক্সেস আছে কিনা তা পরীক্ষা করে, তাই একটি শীর্ষ স্তরের সাইট অন্য কোনও অরিজিনের জন্য অনুমতিগুলি পরীক্ষা করতে পারে।
ব্যবহারকারীকে অনুরোধ করা হবে কিনা বা নির্দিষ্ট অরিজিনে স্টোরেজ অ্যাক্সেস ইতিমধ্যেই মঞ্জুর করা হয়েছে কিনা তা জানতে, navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'}) এ কল করুন।
যদি অনুমতি granted হয়, তাহলে আপনি document.requestStorageAccessFor('https://target.site') কল করতে পারেন। এটি ব্যবহারকারীর কোনও ইঙ্গিত ছাড়াই সফল হবে।
যদি অনুমতিটি prompt হয়, তাহলে আপনাকে ব্যবহারকারীর অঙ্গভঙ্গির পিছনে document.requestStorageAccessFor('https://target.site') কলটি সংযুক্ত করতে হবে, যেমন একটি বোতাম ক্লিক।
উদাহরণ:
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
}
);
}
}
একটি সফল requestStorageAccessFor() কলের পরে, ক্রস-সাইট অনুরোধগুলিতে কুকিজ অন্তর্ভুক্ত থাকবে যদি সেগুলিতে CORS বা crossorigin অ্যাট্রিবিউট থাকে, তাই সাইটগুলি একটি অনুরোধ ট্রিগার করার আগে অপেক্ষা করতে চাইতে পারে।
অনুরোধগুলিতে অবশ্যই credentials: 'include' বিকল্পটি ব্যবহার করতে হবে এবং সংস্থানগুলিতে 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
});
}
স্থানীয়ভাবে কীভাবে পরীক্ষা করবেন
পূর্বশর্ত
স্থানীয়ভাবে সম্পর্কিত ওয়েবসাইট সেট পরীক্ষা করতে, কমান্ড লাইন থেকে চালু হওয়া Chrome 119 বা উচ্চতর সংস্করণ ব্যবহার করুন এবং test-third-party-cookie-phaseout Chrome ফ্ল্যাগ সক্ষম করুন।
Chrome পতাকা সক্ষম করুন
প্রয়োজনীয় Chrome ফ্ল্যাগ সক্ষম করতে, ঠিকানা বার থেকে chrome://flags#test-third-party-cookie-phaseout এ যান এবং ফ্ল্যাগটি Enabled এ পরিবর্তন করুন। ফ্ল্যাগগুলি পরিবর্তন করার পরে ব্রাউজারটি পুনরায় চালু করতে ভুলবেন না।
স্থানীয় সম্পর্কিত ওয়েবসাইট সেট সহ Chrome চালু করুন
স্থানীয়ভাবে ঘোষিত সম্পর্কিত ওয়েবসাইট সেট দিয়ে Chrome চালু করতে, একটি JSON অবজেক্ট তৈরি করুন যাতে একটি সেটের সদস্য URL থাকে এবং এটি --use-related-website-set এ পাস করুন।
ফ্ল্যাগ ব্যবহার করে Chromium কীভাবে চালাবেন সে সম্পর্কে আরও জানুন।
--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/
উদাহরণ
স্থানীয়ভাবে সম্পর্কিত ওয়েবসাইট সেট সক্ষম করতে, আপনাকে chrome://flags এ test-third-party-cookie-phaseout সক্ষম করতে হবে এবং কমান্ড-লাইন থেকে --use-related-website-set ফ্ল্যাগ সহ Chrome চালু করতে হবে যেখানে JSON অবজেক্ট থাকবে যা একটি সেটের সদস্য URL গুলি ধারণ করবে।
--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/
আপনার ক্রস-সাইট কুকিতে অ্যাক্সেস আছে কিনা তা যাচাই করুন।
পরীক্ষা করা হচ্ছে এমন সাইটগুলি থেকে API গুলি (rSA বা rSAFor) কল করুন এবং ক্রস-সাইট কুকিগুলিতে অ্যাক্সেস যাচাই করুন।
সম্পর্কিত ওয়েবসাইট সেট জমা দেওয়ার প্রক্রিয়া
ডোমেনের মধ্যে সম্পর্ক ঘোষণা করতে এবং তারা কোন উপসেটের অংশ তা নির্দিষ্ট করতে নিম্নলিখিত পদক্ষেপগুলি গ্রহণ করুন।
১. আপনার RWS শনাক্ত করুন
প্রাসঙ্গিক ডোমেনগুলি চিহ্নিত করুন, যার মধ্যে সেট প্রাইমারি এবং সেট সদস্য অন্তর্ভুক্ত রয়েছে যা সম্পর্কিত ওয়েবসাইট সেটের অংশ হবে। এছাড়াও প্রতিটি সেট সদস্য কোন উপসেট ধরণের অন্তর্ভুক্ত তা চিহ্নিত করুন।
2. আপনার RWS জমা তৈরি করুন
GitHub রিপোজিটরির একটি স্থানীয় কপি (ক্লোন বা ফর্ক) তৈরি করুন। একটি নতুন শাখায় আপনার সেটটি প্রতিফলিত করার জন্য related_website_sets.JSON ফাইলে পরিবর্তন করুন। আপনার সেটটিতে সঠিক JSON ফর্ম্যাটিং এবং কাঠামো রয়েছে তা নিশ্চিত করতে, আপনি JSON জেনারেটর টুল ব্যবহার করতে পারেন।
৩. নিশ্চিত করুন যে আপনার RWS প্রযুক্তিগত প্রয়োজনীয়তা পূরণ করে
সেট গঠনের প্রয়োজনীয়তা এবং সেট বৈধকরণের প্রয়োজনীয়তাগুলি নিশ্চিত করুন।
৪. স্থানীয়ভাবে আপনার RWS পরীক্ষা করুন
আপনার সেট জমা দেওয়ার জন্য একটি পুল রিকোয়েস্ট (PR) তৈরি করার আগে, আপনার জমাটি স্থানীয়ভাবে পরীক্ষা করে দেখুন যে এটি সমস্ত প্রয়োজনীয় পরীক্ষায় উত্তীর্ণ হয়েছে কিনা।
৫. আপনার RWS জমা দিন
related_website_sets.JSON ফাইলে একটি PR তৈরি করে সম্পর্কিত ওয়েবসাইট সেট জমা দিন যেখানে Chrome ক্যানোনিকাল সম্পর্কিত ওয়েবসাইট সেট তালিকা হোস্ট করে। (PR তৈরি করতে একটি GitHub অ্যাকাউন্ট প্রয়োজন, এবং তালিকায় অবদান রাখার আগে আপনাকে একটি Contributor's License Agreement (CLA) স্বাক্ষর করতে হবে।)
একবার PR তৈরি হয়ে গেলে, ধাপ 3 থেকে প্রয়োজনীয়তাগুলি যথাযথভাবে পালন করা হচ্ছে কিনা তা নিশ্চিত করার জন্য একাধিক পরীক্ষা সম্পন্ন করা হয়, যেমন আপনি CLA-তে স্বাক্ষর করেছেন কিনা এবং .well-known ফাইলটি বৈধ কিনা তা নিশ্চিত করা।
সফল হলে, PR নির্দেশ করবে যে চেকগুলি পাস করা হয়েছে। অনুমোদিত PRগুলি সপ্তাহে একবার (মঙ্গলবার দুপুর ১২ টায় পূর্ব সময়) ক্যানোনিকাল সম্পর্কিত ওয়েবসাইট সেট তালিকায় ব্যাচে ম্যানুয়ালি মার্জ করা হবে। যদি কোনও চেক ব্যর্থ হয়, তাহলে GitHub-এ PR ব্যর্থতার মাধ্যমে জমাদাতাকে অবহিত করা হবে। জমাদাতা ত্রুটিগুলি সংশোধন করতে এবং PR আপডেট করতে পারেন এবং মনে রাখবেন যে:
- যদি PR ব্যর্থ হয়, তাহলে জমা কেন ব্যর্থ হয়েছে সে সম্পর্কে একটি ত্রুটি বার্তা অতিরিক্ত তথ্য প্রদান করবে। ( উদাহরণস্বরূপ )।
- সেট জমা দেওয়ার সকল প্রযুক্তিগত পরীক্ষা GitHub-এ পরিচালিত হয় এবং ফলস্বরূপ, প্রযুক্তিগত পরীক্ষার ফলে সৃষ্ট সকল জমা ব্যর্থতা GitHub-এ দেখা যাবে।
এন্টারপ্রাইজ নীতিমালা
এন্টারপ্রাইজ ব্যবহারকারীদের চাহিদা পূরণের জন্য Chrome-এর দুটি নীতি রয়েছে:
- যেসব সিস্টেম সম্পর্কিত ওয়েবসাইট সেটের সাথে একীভূত করতে সক্ষম নাও হতে পারে, তারা
RelatedWebsiteSetsEnabledনীতি ব্যবহার করে Chrome এর সমস্ত এন্টারপ্রাইজ ইনস্ট্যান্সে সম্পর্কিত ওয়েবসাইট সেট বৈশিষ্ট্যটি অক্ষম করতে পারে।- কিছু এন্টারপ্রাইজ সিস্টেমে শুধুমাত্র অভ্যন্তরীণ সাইট (যেমন একটি ইন্ট্রানেট) থাকে যার নিবন্ধনযোগ্য ডোমেন তাদের সম্পর্কিত ওয়েবসাইট সেটের ডোমেন থেকে আলাদা। যদি তাদের এই সাইটগুলিকে তাদের সম্পর্কিত ওয়েবসাইট সেটের অংশ হিসাবে বিবেচনা করার প্রয়োজন হয় তবে সেগুলিকে জনসমক্ষে প্রকাশ না করে (কারণ ডোমেনগুলি গোপনীয় হতে পারে), তারা
RelatedWebsiteSetsOverridesনীতি ব্যবহার করে তাদের পাবলিক সম্পর্কিত ওয়েবসাইট সেট তালিকা বৃদ্ধি বা ওভাররাইড করতে পারে।
- কিছু এন্টারপ্রাইজ সিস্টেমে শুধুমাত্র অভ্যন্তরীণ সাইট (যেমন একটি ইন্ট্রানেট) থাকে যার নিবন্ধনযোগ্য ডোমেন তাদের সম্পর্কিত ওয়েবসাইট সেটের ডোমেন থেকে আলাদা। যদি তাদের এই সাইটগুলিকে তাদের সম্পর্কিত ওয়েবসাইট সেটের অংশ হিসাবে বিবেচনা করার প্রয়োজন হয় তবে সেগুলিকে জনসমক্ষে প্রকাশ না করে (কারণ ডোমেনগুলি গোপনীয় হতে পারে), তারা
replacements বা additions নির্দিষ্ট করা হয়েছে কিনা তার উপর নির্ভর করে, Chrome দুটি উপায়ের একটিতে পাবলিক এবং এন্টারপ্রাইজ সেটের যেকোনো ছেদ সমাধান করে।
উদাহরণস্বরূপ, পাবলিক সেটের জন্য {primary: A, associated: [B, C]} :
replacements সেট: | {primary: C, associated: [D, E]} |
| এন্টারপ্রাইজ সেট একটি নতুন সেট তৈরি করতে সাধারণ সাইটটি শোষণ করে। | |
| ফলাফল সেট: | {primary: A, associated: [B]}{primary: C, associated: [D, E]} |
additions সেট: | {primary: C, associated: [D, E]} |
| পাবলিক এবং এন্টারপ্রাইজ সেট একত্রিত করা হয়েছে। | |
| ফলাফল সেট: | {primary: C, associated: [A, B, D, E]} |
সম্পর্কিত ওয়েবসাইট সেটগুলির সমস্যা সমাধান করুন
"ব্যবহারকারীর প্রম্পট" এবং "ব্যবহারকারীর অঙ্গভঙ্গি"
"ব্যবহারকারী প্রম্পট" এবং "ব্যবহারকারীর অঙ্গভঙ্গি" ভিন্ন জিনিস। একই সম্পর্কিত ওয়েবসাইট সেটে থাকা সাইটগুলির জন্য Chrome ব্যবহারকারীদের অনুমতি প্রম্পট দেখাবে না, তবে Chrome এখনও ব্যবহারকারীর পৃষ্ঠার সাথে ইন্টারঅ্যাক্ট করা প্রয়োজন। অনুমতি দেওয়ার আগে, Chrome-এর একটি ব্যবহারকারীর অঙ্গভঙ্গি প্রয়োজন, যা "ব্যবহারকারীর ইন্টারঅ্যাকশন" বা "ব্যবহারকারী সক্রিয়করণ" নামেও পরিচিত। এর requestStorageAccess() হল ওয়েব প্ল্যাটফর্ম ডিজাইন নীতির কারণে, সম্পর্কিত ওয়েবসাইট সেট প্রসঙ্গের বাইরে স্টোরেজ অ্যাক্সেস API ব্যবহারের জন্যও একটি ব্যবহারকারীর অঙ্গভঙ্গি প্রয়োজন।
অন্যান্য সাইটের কুকিজ বা স্টোরেজ অ্যাক্সেস করুন
Related Website Sets বিভিন্ন সাইটের জন্য স্টোরেজ একত্রিত করে না: এটি কেবল সহজ (প্রম্পট-মুক্ত) requestStorageAccess() কলগুলিকে অনুমতি দেয়। Related Website Sets শুধুমাত্র Storage Access API ব্যবহার করার সময় ব্যবহারকারীর ঘর্ষণ কমায়, কিন্তু অ্যাক্সেস পুনরুদ্ধার করার পরে কী করতে হবে তা নির্দেশ করে না। যদি A এবং B একই Related Website Set-এর বিভিন্ন সাইট হয় এবং A B এম্বেড করে, তাহলে B requestStorageAccess() কল করতে পারে এবং ব্যবহারকারীকে অনুরোধ না করেই প্রথম-পক্ষের স্টোরেজে অ্যাক্সেস পেতে পারে। Related Website Sets কোনও ক্রস-সাইট যোগাযোগ করে না। উদাহরণস্বরূপ, Related Website Set সেট আপ করার ফলে B-এর কুকিগুলি A-তে পাঠানো শুরু হবে না। আপনি যদি সেই ডেটা শেয়ার করতে চান, তাহলে আপনাকে এটি নিজেই শেয়ার করতে হবে, উদাহরণস্বরূপ একটি B iframe থেকে A ফ্রেমে একটি window.postMessage পাঠিয়ে।
ডিফল্টরূপে পার্টিশনবিহীন কুকি অ্যাক্সেস
সম্পর্কিত ওয়েবসাইট সেটগুলি কোনও API ব্যবহার না করে অন্তর্নিহিত পার্টিশনবিহীন কুকি অ্যাক্সেসের অনুমতি দেয় না। সেটের মধ্যে ডিফল্টভাবে ক্রস-সাইট কুকিজ উপলব্ধ করা হয় না; সম্পর্কিত ওয়েবসাইট সেটগুলি কেবল সেটের মধ্যে থাকা সাইটগুলিকে স্টোরেজ অ্যাক্সেস API অনুমতি প্রম্পট এড়িয়ে যাওয়ার অনুমতি দেয়। একটি আইফ্রেম যদি তার কুকিজ অ্যাক্সেস করতে চায় তবে অবশ্যই document.requestStorageAccess() কল করতে হবে, অথবা শীর্ষ-স্তরের পৃষ্ঠাটি document.requestStorageAccessFor() কল করতে পারে।
মতামত শেয়ার করুন
GitHub-এ একটি সেট জমা দেওয়া এবং Storage Access API এবং requestStorageAccessFor API-এর সাথে কাজ করার মাধ্যমে আপনি প্রক্রিয়াটি এবং আপনার যেকোনো সমস্যার সম্মুখীন হওয়ার অভিজ্ঞতা ভাগ করে নিতে পারবেন।
সম্পর্কিত ওয়েবসাইট সেট সম্পর্কে আলোচনায় যোগদানের জন্য:
- সম্পর্কিত ওয়েবসাইটে যোগদান করুন পাবলিক মেইলিং তালিকা সেট করে।
- সম্পর্কিত ওয়েবসাইট সেটস গিটহাব রেপোতে সমস্যাগুলি উত্থাপন করুন এবং আলোচনা অনুসরণ করুন।