স্টোরেজ অ্যাক্সেস API

ব্রাউজার, ব্যবহারকারীর সেটিংস এবং স্টোরেজ পার্টিশন দ্বারা তৃতীয় পক্ষের কুকি ব্লক করা, ব্যবহারকারীর যাত্রা যেমন প্রমাণীকরণের জন্য এমবেডেড প্রসঙ্গে কুকিজ এবং অন্যান্য স্টোরেজের উপর নির্ভর করে এমন সাইট এবং পরিষেবাগুলির জন্য একটি চ্যালেঞ্জ তৈরি করে৷ স্টোরেজ অ্যাক্সেস API (SAA) এই ব্যবহারের ক্ষেত্রেগুলিকে কাজ চালিয়ে যেতে দেয়, যখন ক্রস-সাইট ট্র্যাকিং যতটা সম্ভব সীমিত করে।

বাস্তবায়নের অবস্থা

Browser Support

• 119
• 85
• 65
• 11.1

Source

স্টোরেজ অ্যাক্সেস API সমস্ত প্রধান ব্রাউজারে উপলব্ধ, কিন্তু ব্রাউজারগুলির মধ্যে সামান্য বাস্তবায়ন পার্থক্য রয়েছে। এই পার্থক্যগুলি এই পোস্টে প্রাসঙ্গিক বিভাগে হাইলাইট করা হয়েছে।

এপিআই মানককরণের আগে সমস্ত অবশিষ্ট ব্লকিং সমস্যা সমাধানের জন্য কাজ অব্যাহত রয়েছে।

স্টোরেজ অ্যাক্সেস API কি?

স্টোরেজ অ্যাক্সেস এপিআই হল একটি জাভাস্ক্রিপ্ট এপিআই যা আইফ্রেমকে স্টোরেজ অ্যাক্সেসের অনুমতির অনুরোধ করার অনুমতি দেয় যখন অ্যাক্সেস অন্যথায় ব্রাউজার সেটিংস দ্বারা অস্বীকার করা হবে। ক্রস-সাইট রিসোর্স লোড করার উপর নির্ভর করে এমন ব্যবহারের ক্ষেত্রে এম্বেড করা প্রয়োজন অনুযায়ী ব্যবহারকারীর কাছ থেকে অ্যাক্সেসের অনুমতির অনুরোধ করতে API ব্যবহার করতে পারে।

যদি স্টোরেজ অনুরোধটি মঞ্জুর করা হয়, তাহলে iframe এর অ-বিভাগহীন কুকিজ এবং স্টোরেজের অ্যাক্সেস থাকবে, যা ব্যবহারকারীরা যখন এটিকে একটি শীর্ষ-স্তরের সাইট হিসাবে পরিদর্শন করে তখনও উপলব্ধ।

স্টোরেজ অ্যাক্সেস এপিআই নির্দিষ্ট বিভাজনবিহীন কুকি এবং স্টোরেজ অ্যাক্সেসকে শেষ ব্যবহারকারীর জন্য ন্যূনতম বোঝা প্রদানের অনুমতি দেয়, যদিও এখনও জেনেরিক আন-পার্টিশনড কুকি এবং স্টোরেজ অ্যাক্সেস প্রতিরোধ করে যেমনটি প্রায়শই ব্যবহারকারীর ট্র্যাকিংয়ের জন্য ব্যবহৃত হয়।

কেস ব্যবহার করুন

কিছু থার্ড-পার্টি এম্বেডের জন্য ব্যবহারকারীকে আরও ভালো অভিজ্ঞতা প্রদানের জন্য আন-পার্টিশনড কুকিজ বা স্টোরেজ অ্যাক্সেসের প্রয়োজন হয়—যেটি তৃতীয় পক্ষের কুকিজ সীমাবদ্ধ থাকলে এবং স্টোরেজ বিভাজন সক্ষম করা থাকলে উপলব্ধ হবে না।

ব্যবহারের ক্ষেত্রে অন্তর্ভুক্ত:

• এম্বেড করা মন্তব্য উইজেট যার জন্য লগইন সেশনের বিবরণ প্রয়োজন।
• সোশ্যাল মিডিয়া "লাইক" বোতাম যার জন্য লগইন সেশনের বিশদ প্রয়োজন।
• এমবেডেড নথি যার জন্য লগইন সেশনের বিশদ প্রয়োজন।
• একটি ভিডিও এম্বেডের জন্য প্রদত্ত একটি প্রিমিয়াম অভিজ্ঞতা (উদাহরণস্বরূপ, লগ ইন করা ব্যবহারকারীদের জন্য বিজ্ঞাপন না দেখানো, বা বন্ধ ক্যাপশনের জন্য ব্যবহারকারীর পছন্দগুলি জানা বা নির্দিষ্ট ভিডিও ধরনের সীমাবদ্ধ করা)।
• এমবেডেড পেমেন্ট সিস্টেম।

এই ব্যবহারের ক্ষেত্রে অনেকগুলি এমবেডেড আইফ্রেমে লগইন অ্যাক্সেসের সাথে জড়িত।

অন্যান্য API-এর উপর কখন স্টোরেজ অ্যাক্সেস API ব্যবহার করবেন

স্টোরেজ অ্যাক্সেস API হল অ-বিভাগহীন কুকিজ এবং স্টোরেজ ব্যবহারের বিকল্পগুলির মধ্যে একটি, তাই অন্যদের তুলনায় কখন এই API ব্যবহার করতে হবে তা বোঝা গুরুত্বপূর্ণ। এটি ব্যবহারের ক্ষেত্রে বোঝানো হয়েছে যেখানে নিম্নলিখিত উভয়ই সত্য:

• ব্যবহারকারী এমবেড করা বিষয়বস্তুর সাথে ইন্টারঅ্যাক্ট করবে—অর্থাৎ, এটি একটি প্যাসিভ আইফ্রেম বা লুকানো আইফ্রেম নয়।
• ব্যবহারকারী একটি শীর্ষ-স্তরের প্রেক্ষাপটে এমবেড করা উত্সটি পরিদর্শন করেছেন—অর্থাৎ যখন সেই উত্সটি অন্য কোনও সাইটে এম্বেড করা হয় না৷

বিভিন্ন ব্যবহারের ক্ষেত্রে বিকল্প API আছে:

• স্বাধীন পার্টিশনড স্টেট থাকা কুকিজ (CHIPS) ডেভেলপারদের শীর্ষ-স্তরের সাইট প্রতি একটি পৃথক কুকি জার সহ "পার্টিশনড" স্টোরেজে একটি কুকি অপ্ট-ইন করতে দেয়। উদাহরণস্বরূপ, একটি তৃতীয় পক্ষের ওয়েব-চ্যাট উইজেট সেশনের তথ্য সংরক্ষণ করতে একটি কুকি সেট করার উপর নির্ভর করতে পারে। সেশনের তথ্য প্রতি-সাইটে সংরক্ষিত হয়, তাই উইজেট দ্বারা সেট করা কুকি অন্য ওয়েবসাইটগুলিতে অ্যাক্সেস করার প্রয়োজন হয় না যেখানে এটি এমবেড করা আছে। স্টোরেজ অ্যাক্সেস API উপযোগী হয় যখন একটি এমবেডেড তৃতীয় পক্ষের উইজেট বিভিন্ন উৎস জুড়ে একই তথ্য ভাগ করার উপর নির্ভর করে (উদাহরণস্বরূপ লগ ইন করা সেশনের বিবরণ বা পছন্দের জন্য)।
• স্টোরেজ পার্টিশনিং হল ক্রস-সাইট আইফ্রেমের জন্য একটি উপায় যেখানে বিদ্যমান জাভাস্ক্রিপ্ট স্টোরেজ মেকানিজম ব্যবহার করার সময় অন্তর্নিহিত স্টোরেজ প্রতি-সাইটে ভাগ করা যায়। এটি একটি ওয়েবসাইটে এম্বেড করা স্টোরেজকে অন্য ওয়েবসাইটে একই এম্বেড দ্বারা অ্যাক্সেস করা থেকে বাধা দেয়।
• সম্পর্কিত ওয়েবসাইট সেট (RWS) হল একটি প্রতিষ্ঠানের জন্য সাইটগুলির মধ্যে সম্পর্ক ঘোষণা করার একটি উপায়, যাতে ব্রাউজারগুলি নির্দিষ্ট উদ্দেশ্যে সীমিত অ-বিভাগহীন কুকি এবং স্টোরেজ অ্যাক্সেসের অনুমতি দেয়। সাইটগুলিকে এখনও স্টোরেজ অ্যাক্সেস API দিয়ে অ্যাক্সেসের অনুরোধ করতে হবে, তবে সেটের মধ্যে থাকা সাইটগুলির জন্য, ব্যবহারকারীর প্রম্পট ছাড়াই অ্যাক্সেস দেওয়া যেতে পারে।
• ফেডারেটেড ক্রেডেনশিয়াল ম্যানেজমেন্ট (FedCM) হল ফেডারেটেড পরিচয় পরিষেবাগুলির জন্য একটি গোপনীয়তা-সংরক্ষণ পদ্ধতি৷ স্টোরেজ অ্যাক্সেস API অ-বিভাগহীন কুকিজ এবং স্টোরেজ পোস্ট-লগইন অ্যাক্সেসের সাথে কাজ করে। কিছু ব্যবহারের ক্ষেত্রে FedCM স্টোরেজ অ্যাক্সেস API-এর একটি বিকল্প সমাধান প্রদান করে, এবং এটি আরও বেশি লগইন-ভিত্তিক ব্রাউজার প্রম্পট বৈশিষ্ট্যের কারণে পছন্দনীয় হতে পারে। যাইহোক, FedCM গ্রহণ করার জন্য সাধারণত আপনার কোডে অতিরিক্ত পরিবর্তনের প্রয়োজন হয়, উদাহরণস্বরূপ এর HTTP এন্ডপয়েন্ট সমর্থন করার জন্য।
• জালিয়াতি-বিরোধী , বিজ্ঞাপন-সম্পর্কিত , এবং পরিমাপ APIগুলিও বিদ্যমান, এবং স্টোরেজ অ্যাক্সেস API এই উদ্বেগের সমাধান করার উদ্দেশ্যে নয়।

স্টোরেজ অ্যাক্সেস API ব্যবহার করুন

স্টোরেজ অ্যাক্সেস API এর দুটি প্রতিশ্রুত-ভিত্তিক পদ্ধতি রয়েছে:

• Document.hasStorageAccess() (নতুন নামে Document.hasUnpartitionedCookieAccess() Chrome 125 এর অধীনেও উপলব্ধ)
• Document.requestStorageAccess()

এটি পারমিশন এপিআই-এর সাথেও সংহত করে। এটি আপনাকে তৃতীয় পক্ষের প্রসঙ্গে স্টোরেজ-অ্যাক্সেস অনুমতির স্থিতি পরীক্ষা করতে দেয়, যা নির্দেশ করে যে document.requestStorageAccess() -এ একটি কল স্বয়ংক্রিয়ভাবে মঞ্জুর করা হবে কিনা:

• navigator.permissions.query({name: "storage-access"});

hasStorageAccess() পদ্ধতি ব্যবহার করুন

যখন একটি সাইট প্রথম লোড হয়, তখন এটি hasStorageAccess() পদ্ধতি ব্যবহার করে পরীক্ষা করতে পারে যে তৃতীয় পক্ষের কুকিগুলিতে অ্যাক্সেস ইতিমধ্যেই মঞ্জুর করা হয়েছে কিনা।

// 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.
    // Note on page load this will always be false initially so we could be
    // skipped in this example, but including for completeness for when this
    // is not so obvious.
    hasAccess = await document.hasStorageAccess();
    if (!hasAccess) {
      // Handle the lack of access (covered later)
    }
  }
  if (hasAccess) {
    // Use the cookies.
  }
}
handleCookieAccessInit();

সঞ্চয়স্থান অ্যাক্সেস শুধুমাত্র একটি iframe ডকুমেন্টে মঞ্জুর করা হয় যখন এটি requestStorageAccess(), তাই hasStorageAccess() সর্বদা প্রথম দিকে মিথ্যা প্রত্যাবর্তন করবে-যখন একই iframe-এ অন্য একই-অরিজিন ডকুমেন্ট ইতিমধ্যেই অ্যাক্সেস মঞ্জুর করা হয়েছে তখন ছাড়া। অনুদানটি আইফ্রেমের ভিতরে একই-অরিজিন নেভিগেশন জুড়ে সংরক্ষিত হয় বিশেষত এইচটিএমএল ডকুমেন্টের জন্য প্রাথমিক অনুরোধে কুকিজ থাকা প্রয়োজন এমন পৃষ্ঠাগুলির অ্যাক্সেস দেওয়ার পরে পুনরায় লোড করার অনুমতি দেওয়ার জন্য।

requestStorageAccess()

যদি iframe-এর অ্যাক্সেস না থাকে তবে এটি requestStorageAccess() পদ্ধতি ব্যবহার করে অ্যাক্সেসের অনুরোধ করতে হতে পারে:

if (!hasAccess) {
  try {
    await document.requestStorageAccess();
  } catch (err) {
    // Access was not granted and it may be gated behind an interaction
    return;
  }
}

প্রথমবার অনুরোধ করা হলে, ব্যবহারকারীকে একটি ব্রাউজার প্রম্পটের মাধ্যমে এই অ্যাক্সেস অনুমোদন করতে হতে পারে, যার পরে প্রতিশ্রুতিটি সমাধান হবে, বা প্রত্যাখ্যান করা হবে যদি await ব্যবহার করা হয় তাহলে ব্যতিক্রম হবে।

অপব্যবহার রোধ করতে, এই ব্রাউজার প্রম্পটটি শুধুমাত্র ব্যবহারকারীর ইন্টারঅ্যাকশনের পরে দেখানো হবে। তাই iframe লোড হওয়ার সাথে সাথে অবিলম্বে না হয়ে, requestStorageAccess() প্রাথমিকভাবে একজন ব্যবহারকারী-সক্রিয় ইভেন্ট হ্যান্ডলার থেকে কল করা প্রয়োজন:

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);

সতর্কতা: Safari requestStorageAccess() -এ অবশ্যই ব্যবহারকারীর দ্বারা সূচিত ইভেন্ট হ্যান্ডলারে কল করতে হবে, অন্য কোনো মেথড কল (যেমন hasStorageAccess() ) অ্যাক্টিভেশন ব্যবহার করার আগে।

আপনি যদি কুকিজের পরিবর্তে স্থানীয় স্টোরেজ ব্যবহার করতে চান তবে আপনি নিম্নলিখিতগুলি করতে পারেন:

let handle = null;

async function doClick() {
  if (!handle) {
    try {
      handle = await document.requestStorageAccess({localStorage: true});
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

  // Use handle to access unpartitioned local storage.
  handle.localStorage.setItem('foo', 'bar');
}

document.querySelector('#my-button').addEventListener('click', doClick);

অনুমতি অনুরোধ

যখন ব্যবহারকারী প্রথমবার বোতামটি ক্লিক করেন, তখন ব্রাউজার প্রম্পটটি স্বয়ংক্রিয়ভাবে বেশিরভাগ ক্ষেত্রে প্রদর্শিত হবে, সাধারণত ঠিকানা বারে। নিম্নলিখিত স্ক্রিনশটটি Chrome এর প্রম্পটের একটি উদাহরণ দেখায়, তবে অন্যান্য ব্রাউজারগুলির একটি অনুরূপ UI রয়েছে:

Chrome এর স্টোরেজ অ্যাক্সেস API অনুমতি প্রম্পট

মূল পয়েন্ট: Chrome এর জন্য, নিম্নলিখিত 30 দিনের জন্য এই প্রম্পটের প্রয়োজন হবে না। একটি আইফ্রেমের সাথে ইন্টারঅ্যাক্ট করলে তা প্রতিবার আরও 30 দিনের জন্য প্রসারিত হবে। এটি অন্যান্য ব্রাউজারগুলির মতোই ।

প্রম্পটটি ব্রাউজার দ্বারা এড়িয়ে যেতে পারে এবং নির্দিষ্ট পরিস্থিতিতে স্বয়ংক্রিয়ভাবে অনুমতি প্রদান করা যেতে পারে:

• যদি প্রম্পট গ্রহণ করার পর গত 30 দিনে পৃষ্ঠা এবং iframe ব্যবহার করা হয়।
• যদি এমবেড করা iframe একটি সম্পর্কিত ওয়েবসাইট সেটের অংশ হয়।
• যদি FedCM স্টোরেজ অ্যাক্সেসের জন্য একটি বিশ্বাস সংকেত হিসাবে ব্যবহার করা হয়।
• ফায়ারফক্সে, প্রথম পাঁচটি প্রচেষ্টার জন্য পরিচিত ওয়েবসাইটগুলির জন্যও প্রম্পটটি বাদ দেওয়া হয় (যেগুলির সাথে আপনি শীর্ষ স্তরে যোগাযোগ করেছেন)।

বিকল্পভাবে, নির্দিষ্ট পরিস্থিতিতে প্রম্পট না দেখিয়ে পদ্ধতিটি স্বয়ংক্রিয়ভাবে প্রত্যাখ্যান করা যেতে পারে:

• যদি ব্যবহারকারী পূর্বে কোনো আইফ্রেমে নয়, একটি শীর্ষ-স্তরের নথি হিসেবে iframe-এর মালিক সাইটটির সাথে আগে পরিদর্শন এবং ইন্টারঅ্যাক্ট না করে থাকে। এর মানে স্টোরেজ অ্যাক্সেস API শুধুমাত্র এমবেড করা সাইটগুলির জন্য উপযোগী যেগুলি ব্যবহারকারীরা আগে প্রথম পক্ষের প্রসঙ্গে পরিদর্শন করেছেন।
• যদি requestStorageAccess() পদ্ধতিটি একটি ইন্টারঅ্যাকশনের পরে প্রম্পটের পূর্বানুমোদন ছাড়াই ব্যবহারকারীর ইন্টারঅ্যাকশন ইভেন্টের বাইরে কল করা হয়।

যদিও ব্যবহারকারীকে প্রাথমিক ব্যবহারের জন্য অনুরোধ জানানো হবে, পরবর্তী ভিজিটগুলি requestStorageAccess() প্রম্পট ছাড়াই এবং Chrome এবং Firefox-এ ব্যবহারকারীর ইন্টারঅ্যাকশনের প্রয়োজন ছাড়াই। মনে রাখবেন যে সাফারির সর্বদা একটি ব্যবহারকারীর মিথস্ক্রিয়া প্রয়োজন।

মূল পয়েন্ট: এমনকি একবার অনুমতি granted , এটি স্বয়ংক্রিয়ভাবে সমস্ত ফ্রেমকে বিভাজনবিহীন কুকি বা স্টোরেজ অ্যাক্সেস দেয় না। requestStorageAccess() পদ্ধতিটি অবশ্যই প্রতিটি পৃষ্ঠা লোডের প্রতিটি ফ্রেমের দ্বারা কল করা আবশ্যক যার জন্য বিভাজনবিহীন কুকিজ বা স্টোরেজ অ্যাক্সেসের প্রয়োজন। এটি নিশ্চিত করে যে ফ্রেমটি সমস্ত ফ্রেমে অ্যাক্সেস দেওয়ার পরিবর্তে শুধুমাত্র কুকিজ এবং স্টোরেজের অ্যাক্সেস পায় যখন এটির প্রয়োজন হয়।

যেহেতু কুকি এবং স্টোরেজ অ্যাক্সেস প্রম্পট বা ব্যবহারকারীর ইন্টারঅ্যাকশন ছাড়াই মঞ্জুর করা যেতে পারে, তাই প্রায়ই পৃষ্ঠা লোড করার সময় requestStorageAccess() কল করে এই (Chrome এবং Firefox) সমর্থন করে এমন ব্রাউজারগুলিতে ব্যবহারকারীর ইন্টারঅ্যাকশনের আগে পার্টিশনবিহীন কুকি বা স্টোরেজ অ্যাক্সেস পাওয়া সম্ভব। এটি আপনাকে অবিলম্বে বিভাজনহীন কুকিজ এবং স্টোরেজ অ্যাক্সেস করতে এবং ব্যবহারকারীর আইফ্রেমের সাথে ইন্টারঅ্যাক্ট করার আগেই একটি পূর্ণ অভিজ্ঞতা প্রদান করতে পারে। ব্যবহারকারীর ইন্টারঅ্যাকশনের জন্য অপেক্ষা করার চেয়ে কিছু পরিস্থিতিতে এটি একটি ভাল ব্যবহারকারীর অভিজ্ঞতা হতে পারে।

SAA এর জন্য একটি বিশ্বাস সংকেত হিসাবে FedCM

FedCM (ফেডারেটেড ক্রেডেনশিয়াল ম্যানেজমেন্ট) হল ফেডারেটেড আইডেন্টিটি পরিষেবাগুলির জন্য একটি গোপনীয়তা-সংরক্ষণ পদ্ধতি (যেমন "সাইন ইন করুন...") যা তৃতীয় পক্ষের কুকিজ বা নেভিগেশনাল রিডাইরেক্টের উপর নির্ভর করে না।

একজন ব্যবহারকারী যখন FedCM-এর সাথে একটি তৃতীয়-পক্ষ পরিচয় প্রদানকারী (IdP) থেকে কিছু এম্বেড করা বিষয়বস্তু আছে এমন একটি Relying Party (RP) এ লগ ইন করেন, তখন এমবেড করা IdP বিষয়বস্তু স্বয়ংক্রিয়ভাবে নিজস্ব শীর্ষ-স্তরের অ-বিভাগহীন কুকিগুলিতে স্টোরেজ অ্যাক্সেস পেতে পারে। FedCM এর সাথে স্বয়ংক্রিয় স্টোরেজ অ্যাক্সেস সক্ষম করতে, এই শর্তগুলি অবশ্যই পূরণ করতে হবে:

• FedCM প্রমাণীকরণ (ব্যবহারকারীর সাইন-ইন অবস্থা) সক্রিয় হতে হবে।
• RP identity-credentials-get সেট করে নির্বাচন করেছে, উদাহরণস্বরূপ:

<iframe src="https://idp.example" allow="identity-credentials-get"></iframe>

উদাহরণস্বরূপ, একটি idp.example iframe rp.example এ এমবেড করা আছে। ব্যবহারকারী যখন FedCM এর সাথে লগ ইন করে, idp.example iframe তার নিজস্ব টপ-লেভেল কুকিজের জন্য স্টোরেজ অ্যাক্সেসের অনুরোধ করতে পারে।

rp.example ব্যবহারকারীকে পরিচয় প্রদানকারী idp.example দিয়ে লগ ইন করার জন্য একটি FedCM কল করে:

// 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',
    }],
  },
});

ব্যবহারকারী লগ ইন করার পর, IdP idp.example iframe-এর মধ্যে থেকে requestStorageAccess() কল করতে পারে, যতক্ষণ না RP অনুমতি নীতির সাথে এটিকে স্পষ্টভাবে অনুমতি দেয়। ব্যবহারকারী সক্রিয়করণ বা অন্য অনুমতি প্রম্পটের প্রয়োজন ছাড়াই এম্বেডটিকে স্বয়ংক্রিয়ভাবে নিজস্ব শীর্ষ-স্তরের কুকিতে সঞ্চয়স্থানের অ্যাক্সেস দেওয়া হবে:

// 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();

দ্রষ্টব্য: যদি কোনো RP স্বয়ংক্রিয়ভাবে পুনরায় প্রমাণীকরণ নিষ্ক্রিয় করতে navigator.credentials.preventSilentAccess() কল করে, ব্যবহারকারী FedCM-এর সাথে আবার সাইন ইন না করা পর্যন্ত স্টোরেজ অ্যাক্সেসও স্বয়ংক্রিয়ভাবে মঞ্জুর করা হবে না। document.requestStorageAccess() এর একটি আহ্বান এই ক্ষেত্রে ব্যবহারকারীকে একটি প্রম্পট দেখানোর জন্য ফিরে আসতে পারে।

অনুমতি স্বয়ংক্রিয়ভাবে মঞ্জুর করা হবে যতক্ষণ না ব্যবহারকারী FedCM-এর সাথে সাইন ইন করবেন। একবার প্রমাণীকরণ নিষ্ক্রিয় হয়ে গেলে, স্টোরেজ অ্যাক্সেস দেওয়ার জন্য স্ট্যান্ডার্ড SAA প্রয়োজনীয়তা প্রযোজ্য।

স্টোরেজ অ্যাক্সেস হেডার সহ পরবর্তী লোডিং

সঞ্চয়স্থান অ্যাক্সেস শিরোনাম হল একটি প্রস্তাবিত, অ-আইফ্রেম সংস্থান সহ এমবেডেড সামগ্রীর লোডিং সক্ষম করার আরও কার্যকর উপায়৷ বৈশিষ্ট্যটি Chrome 133 থেকে পাওয়া যায়। স্টোরেজ অ্যাক্সেস হেডারের সাহায্যে, ব্রাউজারটি সনাক্ত করতে পারে যখন ব্যবহারকারী ইতিমধ্যেই বর্তমান প্রেক্ষাপটে তৃতীয় পক্ষের উত্সকে storage-access অনুমতি দিয়েছে এবং পরবর্তী ভিজিটের সময় অ-বিভাজন কুকিগুলিতে অ্যাক্সেস সহ সংস্থানগুলি লোড করতে পারে।

স্টোরেজ অ্যাক্সেস হেডার প্রবাহ

গুরুত্বপূর্ণ: প্রাথমিক অনুমতির অনুরোধ করতে স্টোরেজ অ্যাক্সেস হেডার ব্যবহার করা যাবে না। ওয়েবসাইটগুলিকে এখনও অনুমতি না দেওয়া হলে ব্যবহারকারীর অনুমতির অনুরোধ করার জন্য সম্পর্কিত ওয়েবসাইট সেটগুলির মধ্যে একটি iframe কলিং document.requestStorageAccess() বা document.requestStorageAccessFor() এম্বেড করতে হবে৷

স্টোরেজ অ্যাক্সেস হেডারের সাহায্যে, পরবর্তী পৃষ্ঠা পরিদর্শন নিম্নলিখিত প্রবাহকে ট্রিগার করবে:

1. ব্যবহারকারী পূর্বে website.example পরিদর্শন করেছেন যা একটি calendar.example সম্পদ এম্বেড করে এবং document.requestStorageAccess() কলের সাথে storage-access মঞ্জুর করেছে।
2. ব্যবহারকারী website.example পরিদর্শন করে যেখানে calendar.example রিসোর্স আবার এমবেড করা আছে। এই অনুরোধের এখনও আগের মতো কুকিতে অ্যাক্সেস নেই৷ যাইহোক, ব্যবহারকারী পূর্বে storage-access অনুমতি দিয়েছে, এবং আনয়নে একটি Sec-Fetch-Storage-Access: inactive শিরোনাম রয়েছে, এটি নির্দেশ করতে যে অ-বিভাগহীন কুকি অ্যাক্সেস উপলব্ধ কিন্তু সক্রিয় নয়।
3. calendar.example সার্ভার একটি Activate-Storage-Access: retry; allowed-origin='<origin>' শিরোনাম (এই ক্ষেত্রে, <origin> হবে https://website.example ), ইঙ্গিত করার জন্য যে রিসোর্স আনয়নের জন্য storage-access অনুমতি সহ অ-বিভাগহীন কুকি ব্যবহার করা প্রয়োজন।
4. ব্রাউজার অনুরোধটি পুনরায় চেষ্টা করে, এইবার বিভাজনবিহীন কুকিজ সহ (এই আনয়ন এবং পরবর্তী আনার জন্য storage-access অনুমতি সক্রিয় করা)।
5. calendar.example সার্ভার ব্যক্তিগতকৃত iframe বিষয়বস্তুর সাথে সাড়া দেয়। প্রতিক্রিয়াটিতে একটি Activate-Storage-Access: load শিরোনাম রয়েছে, এটি নির্দেশ করতে যে ব্রাউজারটিকে storage-access অনুমতি সক্রিয় করা সহ সামগ্রী লোড করা উচিত (অন্য কথায়, অ-বিভাগহীন কুকি অ্যাক্সেস সহ লোড করুন, যেন document.requestStorageAccess() বলা হয়েছে)।
6. ব্যবহারকারী এজেন্ট storage-access অনুমতি ব্যবহার করে বিভাজনবিহীন কুকি অ্যাক্সেস সহ iframe সামগ্রী লোড করে। এই ধাপের পরে, উইজেটটি প্রত্যাশা অনুযায়ী কাজ করতে পারে।

সতর্কতা: storage-access অনুমতি Chrome এবং Firefox-এ সমর্থিত, কিন্তু Safari-এ নয়। Safari ব্যবহারকারীদের জন্য, একটি ব্যবহারকারীর মিথস্ক্রিয়া সর্বদা প্রয়োজন (অ্যাক্সেস মঞ্জুর করার পরে একটি পৃষ্ঠা পুনরায় লোড করার বিশেষ ব্যবহারের ক্ষেত্রে ব্যতীত)।

স্টোরেজ অ্যাক্সেস হেডার ফ্লো ডায়াগ্রাম।

স্টোরেজ অ্যাক্সেস হেডার ব্যবহার করুন

নিম্নলিখিত সারণী স্টোরেজ অ্যাক্সেস হেডার তালিকাভুক্ত করে।

প্রবাহ	হেডার	মান	বর্ণনা
অনুরোধ	Sec-Fetch-Storage-Access দ্রষ্টব্য: ব্রাউজার স্বয়ংক্রিয়ভাবে এই শিরোনামটি ক্রস-সাইট অনুরোধে পাঠায় যাতে শংসাপত্র অন্তর্ভুক্ত থাকে (উদাহরণস্বরূপ, new Request('request.example', { credentials: 'include' }); )।	none	এম্বেডের কোনো স্টোরেজ অ্যাক্সেসের অনুমতি নেই।
		inactive	এম্বেডের অনুমতি আছে, কিন্তু এটি ব্যবহার করছে না। অনুরোধে Origin হেডারও অন্তর্ভুক্ত করতে হবে।
		active	এম্বেডের অ-বিভাজন কুকি অ্যাক্সেস রয়েছে।
প্রতিক্রিয়া	Activate-Storage-Access	load	অনুরোধ করা সংস্থানটির জন্য বিভাজনবিহীন কুকিগুলিতে এমবেডার অ্যাক্সেস দেওয়ার জন্য ব্রাউজারকে নির্দেশ দেয়৷ যদি storage-access অনুমতি দেওয়া হয় তবে এই শিরোনামটি অন্তর্ভুক্ত করা document.requestStorageAccess() কল করার সমতুল্য। এর মানে ব্যবহারকারীর কাছে কোনো অতিরিক্ত প্রম্পট প্রদর্শিত হবে না।
		retry	স্টোরেজ-অ্যাক্সেস অনুমতি সক্রিয় করতে ব্রাউজারকে নির্দেশ দেয়, এবং তারপর অনুরোধটি পুনরায় চেষ্টা করুন।
	allowed-origin	<origin>	শংসাপত্রযুক্ত অনুরোধগুলি শুরু করার জন্য কোন উত্সকে অনুমতি দেওয়া হয়েছে তা নির্দিষ্ট করে (যেমন, https://site.example বা * )।

উদাহরণস্বরূপ, স্টোরেজ অ্যাক্সেস হেডারগুলি একটি তৃতীয় পক্ষ থেকে একটি ইমেজ ইমেজ লোড করতে ব্যবহার করা যেতে পারে:

  // On the client side
  <img src="https://server.example/image">

এই ক্ষেত্রে, server.example সার্ভার সাইডে নিম্নলিখিত যুক্তি প্রয়োগ করা উচিত:

  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')
  }
});

স্টোরেজ অ্যাক্সেস এপিআই ডেমো স্টোরেজ অ্যাক্সেস হেডার ব্যবহার করে তৃতীয়-পক্ষের সামগ্রী (একটি নন-আইফ্রেম ছবি সহ) এম্বেড করে।

storage-access অনুমতি প্রশ্ন ব্যবহার করুন

ব্যবহারকারীর মিথস্ক্রিয়া ছাড়াই অ্যাক্সেস দেওয়া যায় কিনা তা পরীক্ষা করার জন্য, আপনি storage-access অনুমতির স্থিতি পরীক্ষা করতে পারেন এবং শুধুমাত্র requestStoreAccess() তাড়াতাড়ি কল করতে পারেন যদি কোনও ব্যবহারকারীর অ্যাকশনের প্রয়োজন না হয়, এটিকে কল করার পরিবর্তে এবং যখন কোনও ইন্টারঅ্যাকশন প্রয়োজন হয় তখন এটি ব্যর্থ হয়।

এটি আপনাকে বিভিন্ন বিষয়বস্তু প্রদর্শনের মাধ্যমে সম্ভাব্যভাবে একটি প্রম্পট আপফ্রন্টের প্রয়োজনীয়তা পরিচালনা করতে দেয়—উদাহরণস্বরূপ, একটি লগইন বোতাম।

সতর্কতা: storage-access অনুমতি Chrome এবং Firefox-এ সমর্থিত, কিন্তু Safari-এ নয়। Safari ব্যবহারকারীদের জন্য, একটি ব্যবহারকারীর মিথস্ক্রিয়া সর্বদা প্রয়োজন (অ্যাক্সেস মঞ্জুর করার পরে একটি পৃষ্ঠা পুনরায় লোড করার বিশেষ ব্যবহারের ক্ষেত্রে ব্যতীত)।

নিম্নলিখিত কোডটি আগের উদাহরণে storage-access অনুমতি চেক যোগ করে:

// 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();

মূল পয়েন্ট: গোপনীয়তার কারণে, প্রম্পটটি দেখানো হয়েছে এবং প্রত্যাখ্যান করা হয়েছে কিনা বা ব্রাউজার হিউরিস্টিকসের উপর ভিত্তি করে দেখানো হয়নি তা বলা সম্ভব নয় —দুটোই আবার জিজ্ঞাসা করলেও বর্তমান অবস্থা হিসাবে prompt ফিরে আসবে।

স্যান্ডবক্সযুক্ত আইফ্রেম

স্যান্ডবক্সড আইফ্রেমে স্টোরেজ অ্যাক্সেস API ব্যবহার করার সময়, নিম্নলিখিত স্যান্ডবক্স অনুমতিগুলির প্রয়োজন হয়:

• সঞ্চয়স্থান অ্যাক্সেস API-এ অ্যাক্সেসের অনুমতি দেওয়ার জন্য allow-storage-access-by-user-activation প্রয়োজন।
• API কল করার জন্য JavaScript ব্যবহার করার অনুমতি দেওয়ার জন্য allow-scripts প্রয়োজন হয়।
• একই allow-same-origin প্রয়োজন।

যেমন:

<iframe sandbox="allow-storage-access-by-user-activation
                 allow-scripts
                 allow-same-origin"
        src="..."></iframe>

কুকি প্রয়োজনীয়তা

ক্রোমে স্টোরেজ অ্যাক্সেস API-এর মাধ্যমে অ্যাক্সেস করতে, ক্রস-সাইট কুকিগুলি নিম্নলিখিত দুটি বৈশিষ্ট্যের সাথে সেট করতে হবে:

• SameSite=None - যা কুকিকে ক্রস-সাইট হিসেবে চিহ্নিত করতে হবে
• Secure - যা নিশ্চিত করে যে শুধুমাত্র HTTPS সাইট দ্বারা সেট করা কুকিগুলি অ্যাক্সেস করা যেতে পারে৷

Firefox এবং Safari-এ, SameSite=None এ কুকিজ ডিফল্ট হয় এবং তারা SAA-কে Secure কুকিতে সীমাবদ্ধ করে না তাই এই বৈশিষ্ট্যগুলির প্রয়োজন হয় না। SameSite অ্যাট্রিবিউট সম্পর্কে স্পষ্ট হওয়া এবং সর্বদা Secure কুকিজ ব্যবহার করার পরামর্শ দেওয়া হয়।

শীর্ষ-স্তরের পৃষ্ঠা অ্যাক্সেস

স্টোরেজ অ্যাক্সেস এপিআইটি এমবেডেড আইফ্রেমের মধ্যে তৃতীয় পক্ষের কুকিগুলিতে অ্যাক্সেস সক্ষম করার উদ্দেশ্যে তৈরি৷

এছাড়াও অন্যান্য ব্যবহারের ক্ষেত্রে রয়েছে যখন শীর্ষ-স্তরের পৃষ্ঠার তৃতীয়-পক্ষ কুকিগুলিতে অ্যাক্সেসের প্রয়োজন হয়। উদাহরণস্বরূপ, ছবি বা স্ক্রিপ্ট যা কুকি দ্বারা সীমাবদ্ধ, কোন সাইটের মালিকরা আইফ্রেমের পরিবর্তে সরাসরি শীর্ষ-স্তরের নথিতে অন্তর্ভুক্ত করতে চাইতে পারেন। এই ব্যবহারের ক্ষেত্রে ক্রোম স্টোরেজ অ্যাক্সেস API-তে একটি এক্সটেনশন প্রস্তাব করেছে যা একটি requestStorageAccessFor() পদ্ধতি যোগ করে।

requestStorageAccessFor() পদ্ধতি

Browser Support

• 119
• 119
• x
• x

Source

requestStorageAccessFor() পদ্ধতি requestStorageAccess() এর মতোই কাজ করে কিন্তু শীর্ষ-স্তরের সংস্থানগুলির জন্য। এটি শুধুমাত্র একটি সম্পর্কিত ওয়েবসাইট সেটের মধ্যে থাকা সাইটগুলির জন্য ব্যবহার করা যেতে পারে যাতে তৃতীয় পক্ষের কুকিগুলিতে সাধারণ অ্যাক্সেস দেওয়া প্রতিরোধ করা যায়।

requestStorageAccessFor() কীভাবে ব্যবহার করবেন সে সম্পর্কে আরও বিশদ বিবরণের জন্য সম্পর্কিত ওয়েবসাইট সেটগুলি পড়ুন: বিকাশকারী নির্দেশিকা ।

top-level-storage-access অনুমতি প্রশ্ন

Browser Support

• 113
• 113
• x
• x

storage-access অনুমতির মতোই, একটি top-level-storage-access অনুমতি আছে যেটি requestStorageAccessFor() এর জন্য অ্যাক্সেস দেওয়া যেতে পারে কিনা তা পরীক্ষা করার জন্য।

RWS এর সাথে ব্যবহার করার সময় স্টোরেজ অ্যাক্সেস API কীভাবে আলাদা?

যখন সম্পর্কিত ওয়েবসাইট সেটগুলি স্টোরেজ অ্যাক্সেস API-এর সাথে ব্যবহার করা হয়, তখন নিম্নলিখিত সারণীতে বিস্তারিত হিসাবে কিছু অতিরিক্ত ক্ষমতা উপলব্ধ থাকে:

	RWS ছাড়া	RWS এর সাথে
স্টোরেজ অ্যাক্সেসের অনুরোধ শুরু করার জন্য একটি ব্যবহারকারীর অঙ্গভঙ্গি প্রয়োজন
অ্যাক্সেস মঞ্জুর করার আগে ব্যবহারকারীকে একটি শীর্ষ-স্তরের প্রেক্ষাপটে অনুরোধকৃত সঞ্চয়স্থানের উৎস দেখতে হবে
প্রথমবার ব্যবহারকারী প্রম্পট এড়িয়ে যেতে পারে
requestStorageAccess কল করার প্রয়োজন নেই যদি আগে অ্যাক্সেস দেওয়া হয়
একটি সম্পর্কিত ওয়েবসাইট সাইটে স্বয়ংক্রিয়ভাবে অন্যান্য ডোমেন জুড়ে অ্যাক্সেস মঞ্জুর করে
শীর্ষ-স্তরের পৃষ্ঠা অ্যাক্সেসের জন্য requestStorageAccessFor সমর্থন করে

সম্পর্কিত ওয়েবসাইট সেট ছাড়া এবং এর সাথে স্টোরেজ অ্যাক্সেস API ব্যবহার করার মধ্যে পার্থক্য

ডেমো: কুকি সেট করা এবং অ্যাক্সেস করা

নিম্নলিখিত ডেমো দেখায় কিভাবে ডেমোর প্রথম স্ক্রিনে নিজের দ্বারা সেট করা একটি কুকি ডেমোর দ্বিতীয় সাইটে এমবেডেড ফ্রেমে অ্যাক্সেস করা যেতে পারে:

store-access-api-demo.glitch.me

ডেমোর জন্য তৃতীয় পক্ষের কুকি অক্ষম সহ একটি ব্রাউজার প্রয়োজন:

• Chrome 118 বা উচ্চতর chrome://flags/#test-third-party-cookie-phaseout পতাকা সেট এবং ব্রাউজার পুনরায় চালু করা হয়েছে।
• ফায়ারফক্স
• সাফারি

ডেমো: স্থানীয় স্টোরেজ সেটিং

নিম্নলিখিত ডেমো দেখায় কিভাবে স্টোরেজ অ্যাক্সেস API ব্যবহার করে তৃতীয় পক্ষের আইফ্রেম থেকে বিভাজনবিহীন ব্রডকাস্ট চ্যানেলগুলি অ্যাক্সেস করতে হয়:

https://saa-beyond-cookies.glitch.me/

টেস্ট-থার্ড-পার্টি-কুকি-ফেজআউট ফ্ল্যাগ সক্ষম সহ ডেমোর জন্য Chrome 125 বা উচ্চতর প্রয়োজন।

সম্পদ

• তৃতীয় পক্ষের কুকি অ্যাক্সেস প্রদানকারী স্পেসিফিকেশন পড়ুন বা অনুসরণ করুন এবং সমস্যাগুলি উত্থাপন করুন।
• বিভাজনবিহীন স্টোরেজ অ্যাক্সেস প্রদানকারী স্পেসিফিকেশন পড়ুন বা অনুসরণ করুন এবং সমস্যাগুলি উত্থাপন করুন।
• API ডকুমেন্টেশন এবং গাইড ।
• সম্পর্কিত ওয়েবসাইট সেটগুলিতে স্টোরেজ অ্যাক্সেস API ব্যবহার করার বিষয়ে Chrome ডকুমেন্টেশন