একইসাইট কুকি রেসিপি

রোয়ান মেরিউড

Chrome , Firefox , Edge , এবং অন্যরা IETF প্রস্তাবের সাথে সামঞ্জস্য রেখে তাদের ডিফল্ট আচরণ পরিবর্তন করবে, ক্রমবর্ধমানভাবে আরও ভাল কুকিজ যাতে:

  • SameSite অ্যাট্রিবিউট ছাড়া কুকিগুলিকে SameSite=Lax হিসাবে গণ্য করা হবে, যার অর্থ ডিফল্ট আচরণ হবে কুকিজকে শুধুমাত্র প্রথম পক্ষের প্রসঙ্গে সীমাবদ্ধ করা।
  • ক্রস-সাইট ব্যবহারের জন্য কুকিজ অবশ্যই উল্লেখ করতে হবে SameSite=None; Secure তৃতীয় পক্ষের প্রসঙ্গে অন্তর্ভুক্তি সক্ষম করতে SameSite=None; Secure ।

এই বৈশিষ্ট্যটি Chrome 84 স্থিতিশীল থেকে ডিফল্ট আচরণ । আপনি যদি ইতিমধ্যে এটি না করে থাকেন তবে আপনার তৃতীয় পক্ষের কুকিজের বৈশিষ্ট্যগুলি আপডেট করা উচিত যাতে ভবিষ্যতে সেগুলি ব্লক করা না হয়৷

ক্রস ব্রাউজার সমর্থন

MDN-এর Set-Cookie পৃষ্ঠার ব্রাউজার সামঞ্জস্যপূর্ণ বিভাগটি দেখুন।

ক্রস-সাইট বা তৃতীয় পক্ষের কুকির জন্য কেস ব্যবহার করুন

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

একটি <iframe> এর মধ্যে সামগ্রী

একটি <iframe> -এ প্রদর্শিত একটি ভিন্ন সাইটের বিষয়বস্তু তৃতীয় পক্ষের প্রেক্ষাপটে। স্ট্যান্ডার্ড ব্যবহারের ক্ষেত্রে এখানে রয়েছে:

  • এম্বেড করা সামগ্রী অন্যান্য সাইট থেকে শেয়ার করা, যেমন ভিডিও, মানচিত্র, কোড নমুনা এবং সামাজিক পোস্ট।
  • অর্থপ্রদান, ক্যালেন্ডার, বুকিং এবং রিজার্ভেশন কার্যকারিতার মতো বাহ্যিক পরিষেবাগুলি থেকে উইজেট।
  • উইজেট যেমন সামাজিক বোতাম বা অ্যান্টি-ফ্রড পরিষেবা যা কম স্পষ্ট <iframes> তৈরি করে।

কুকিজ এখানে ব্যবহার করা যেতে পারে, অন্যান্য জিনিসগুলির মধ্যে, সেশনের অবস্থা বজায় রাখতে, সাধারণ পছন্দগুলি সঞ্চয় করতে, পরিসংখ্যান সক্ষম করতে, বা বিদ্যমান অ্যাকাউন্টগুলির সাথে ব্যবহারকারীদের জন্য সামগ্রী ব্যক্তিগতকৃত করতে।

একটি ব্রাউজার উইন্ডোর ডায়াগ্রাম যেখানে এমবেড করা সামগ্রীর URL পৃষ্ঠার URL এর সাথে মেলে না৷
যদি এম্বেড করা বিষয়বস্তু শীর্ষ-স্তরের ব্রাউজিং প্রসঙ্গ হিসাবে একই সাইট থেকে না আসে তবে এটি তৃতীয় পক্ষের সামগ্রী।

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

সাইট জুড়ে "অনিরাপদ" অনুরোধ

যদিও এখানে "অনিরাপদ" শব্দটি সামান্য মনে হতে পারে, এটি এমন যেকোন অনুরোধকে বোঝায় যা রাষ্ট্র পরিবর্তনের উদ্দেশ্যে হতে পারে। ওয়েবে যা প্রাথমিকভাবে পোস্টের অনুরোধ। SameSite=Lax হিসাবে চিহ্নিত কুকিগুলি নিরাপদ শীর্ষ-স্তরের নেভিগেশনগুলিতে পাঠানো হবে, যেমন একটি ভিন্ন সাইটে যেতে একটি লিঙ্কে ক্লিক করা। যাইহোক, একটি ভিন্ন সাইটে POST-এর মাধ্যমে <form> জমা দেওয়ার মতো কিছু কুকি অন্তর্ভুক্ত করবে না।

এক পৃষ্ঠা থেকে অন্য পৃষ্ঠায় যাওয়ার অনুরোধের চিত্র।
যদি আগত অনুরোধ একটি "নিরাপদ" পদ্ধতি ব্যবহার করে তবে কুকিগুলি পাঠানো হবে।

এই প্যাটার্নটি এমন সাইটগুলির জন্য ব্যবহার করা হয় যেগুলি ব্যবহারকারীকে প্রত্যাবর্তনের আগে কিছু অপারেশন করার জন্য একটি দূরবর্তী পরিষেবাতে পুনঃনির্দেশ করতে পারে, উদাহরণস্বরূপ একটি তৃতীয় পক্ষের পরিচয় প্রদানকারীর কাছে পুনঃনির্দেশ করা। ব্যবহারকারী সাইটটি ছেড়ে যাওয়ার আগে, ক্রস সাইট রিকোয়েস্ট ফোরজি (CSRF) আক্রমণ প্রশমিত করার জন্য রিটার্নিং রিকোয়েস্টে এই টোকেনটি চেক করা যাবে এই প্রত্যাশার সাথে একটি কুকি সেট করা হয় যাতে একটি একক ব্যবহারের টোকেন থাকে। যদি সেই রিটার্নিং রিকোয়েস্টটি POST এর মাধ্যমে আসে তাহলে কুকিগুলিকে SameSite=None; Secure .

দূরবর্তী সম্পদ

একটি পৃষ্ঠার যেকোন দূরবর্তী সংস্থান <img> ট্যাগ, <script> ট্যাগ এবং আরও অনেক কিছু থেকে অনুরোধের সাথে পাঠানোর জন্য কুকিজের উপর নির্ভর করতে পারে। সাধারণ ব্যবহারের ক্ষেত্রে ট্র্যাকিং পিক্সেল এবং সামগ্রী ব্যক্তিগতকরণ অন্তর্ভুক্ত।

এটি আপনার জাভাস্ক্রিপ্ট থেকে fetch বা XMLHttpRequest দ্বারা শুরু করা অনুরোধের ক্ষেত্রেও প্রযোজ্য। যদি fetch() credentials: 'include' বিকল্প এটি একটি ভাল ইঙ্গিত যে কুকিগুলি সেই অনুরোধগুলিতে আশা করা যেতে পারে। XMLHttpRequest এর জন্য আপনার withCredentials প্রপার্টি true সেট করার উদাহরণগুলি সন্ধান করা উচিত। এটি একটি ভাল ইঙ্গিত যে কুকিগুলি সেই অনুরোধগুলিতে আশা করা যেতে পারে৷ ক্রস-সাইট অনুরোধে অন্তর্ভুক্ত করার জন্য সেই কুকিগুলিকে যথাযথভাবে চিহ্নিত করতে হবে।

একটি WebView মধ্যে বিষয়বস্তু

একটি প্ল্যাটফর্ম-নির্দিষ্ট অ্যাপের একটি ওয়েবভিউ একটি ব্রাউজার দ্বারা চালিত হয় এবং একই বিধিনিষেধ বা সমস্যাগুলি প্রযোজ্য কিনা তা আপনাকে পরীক্ষা করতে হবে। অ্যান্ড্রয়েডে, যদি ওয়েবভিউ ক্রোম দ্বারা চালিত হয় তবে নতুন ডিফল্টগুলি অবিলম্বে Chrome 84-এর সাথে প্রয়োগ করা হবে না। তবে উদ্দেশ্য ভবিষ্যতে সেগুলি প্রয়োগ করা, তাই আপনাকে এখনও পরীক্ষা করে এর জন্য প্রস্তুত করা উচিত। উপরন্তু, Android তার প্ল্যাটফর্ম-নির্দিষ্ট অ্যাপগুলিকে সরাসরি CookieManager API-এর মাধ্যমে কুকি সেট করার অনুমতি দেয়। হেডার বা জাভাস্ক্রিপ্টের মাধ্যমে সেট করা কুকির মতো, SameSite=None; Secure সেগুলি ক্রস-সাইট ব্যবহারের উদ্দেশ্যে করা হলে SameSite=None; Secure ৷

কিভাবে আজ SameSite বাস্তবায়ন করবেন

কুকির জন্য যেখানে সেগুলি শুধুমাত্র প্রথম পক্ষের প্রেক্ষাপটে প্রয়োজন হয় আপনি আদর্শভাবে সেগুলিকে আপনার প্রয়োজনের উপর নির্ভর করে SameSite=Lax বা SameSite=Strict হিসাবে চিহ্নিত করা উচিত। আপনি কিছু না করা বেছে নিতে পারেন এবং ব্রাউজারটিকে তার ডিফল্ট প্রয়োগ করার অনুমতি দিতে পারেন, তবে এটি প্রতিটি কুকির জন্য ব্রাউজার জুড়ে অসামঞ্জস্যপূর্ণ আচরণ এবং সম্ভাব্য কনসোল সতর্কতার ঝুঁকি নিয়ে আসে৷

Set-Cookie: first_party_var=value; SameSite=Lax

তৃতীয় পক্ষের প্রেক্ষাপটে প্রয়োজনীয় কুকিগুলির জন্য, আপনাকে নিশ্চিত করতে হবে যে সেগুলি SameSite=None; Secure . মনে রাখবেন যে আপনার উভয় বৈশিষ্ট্য একসাথে প্রয়োজন। আপনি যদি Secure ছাড়া None উল্লেখ করেন তবে কুকি প্রত্যাখ্যান করা হবে। যদিও ব্রাউজার বাস্তবায়নে কিছু পারস্পরিক বেমানান পার্থক্য রয়েছে, তাই আপনাকে নীচের বেমানান ক্লায়েন্ট হ্যান্ডলিং -এ বর্ণিত কিছু প্রশমন কৌশল ব্যবহার করতে হতে পারে।

Set-Cookie: third_party_var=value; SameSite=None; Secure

বেমানান ক্লায়েন্ট হ্যান্ডলিং

যেহেতু এই পরিবর্তনগুলি None অন্তর্ভুক্ত এবং ডিফল্ট আচরণ আপডেট করার জন্য এখনও তুলনামূলকভাবে নতুন, এই পরিবর্তনগুলি কীভাবে পরিচালনা করা হয় সে সম্পর্কে ব্রাউজারগুলির মধ্যে অসঙ্গতি রয়েছে। আপনি বর্তমানে পরিচিত সমস্যাগুলির জন্য chromium.org-এ আপডেট পৃষ্ঠাটি উল্লেখ করতে পারেন, তবে এটি সম্পূর্ণ কিনা তা বলা সম্ভব নয়৷ যদিও এটি আদর্শ নয়, তবে এই ক্রান্তিকালীন পর্যায়ে আপনি নিয়োগ করতে পারেন এমন কিছু সমাধান রয়েছে। যদিও সাধারণ নিয়ম হল বেমানান ক্লায়েন্টদের বিশেষ ক্ষেত্রে হিসাবে বিবেচনা করা। ব্রাউজারগুলি নতুন নিয়ম বাস্তবায়নের জন্য একটি ব্যতিক্রম তৈরি করবেন না।

প্রথম বিকল্পটি হল নতুন এবং পুরানো উভয় স্টাইল কুকি সেট করা:

Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure

নতুন আচরণ বাস্তবায়নকারী ব্রাউজাররা SameSite মান সহ কুকি সেট করবে, যখন অন্যান্য ব্রাউজার এটি উপেক্ষা বা ভুলভাবে সেট করতে পারে। যাইহোক, সেই একই ব্রাউজার 3pcookie-legacy কুকি সেট করবে। অন্তর্ভুক্ত কুকি প্রক্রিয়া করার সময়, সাইটটিকে প্রথমে নতুন শৈলীর কুকির উপস্থিতি পরীক্ষা করা উচিত এবং যদি এটি খুঁজে না পাওয়া যায়, তাহলে লিগ্যাসি কুকিতে ফিরে যেতে হবে৷

এক্সপ্রেস ফ্রেমওয়ার্ক এবং এর কুকি-পার্সার মিডলওয়্যার ব্যবহার করে Node.js-এ কীভাবে এটি করা যায় তা নীচের উদাহরণে দেখানো হয়েছে।

const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());

app.get('/set', (req, res) => {
  // Set the new style cookie
  res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
  // And set the same value in the legacy cookie
  res.cookie('3pcookie-legacy', 'value', { secure: true });
  res.end();
});

app.get('/', (req, res) => {
  let cookieVal = null;

  if (req.cookies['3pcookie']) {
    // check the new style cookie first
    cookieVal = req.cookies['3pcookie'];
  } else if (req.cookies['3pcookie-legacy']) {
    // otherwise fall back to the legacy cookie
    cookieVal = req.cookies['3pcookie-legacy'];
  }

  res.end();
});

app.listen(process.env.PORT);

নেতিবাচক দিক হল যে এতে সমস্ত ব্রাউজার কভার করার জন্য অপ্রয়োজনীয় কুকি সেট করা জড়িত এবং কুকি সেটিং এবং পড়ার উভয় ক্ষেত্রেই পরিবর্তন করা প্রয়োজন৷ যাইহোক, এই পদ্ধতির সমস্ত ব্রাউজারকে তাদের আচরণ নির্বিশেষে কভার করা উচিত এবং তৃতীয় পক্ষের কুকিগুলি আগের মতো কাজ করা চালিয়ে যাওয়া নিশ্চিত করা উচিত।

বিকল্পভাবে Set-Cookie হেডার পাঠানোর সময়ে, আপনি ব্যবহারকারী এজেন্ট স্ট্রিং এর মাধ্যমে ক্লায়েন্ট সনাক্ত করতে পারেন। বেমানান ক্লায়েন্টদের তালিকা পড়ুন এবং তারপর আপনার প্ল্যাটফর্মের জন্য একটি উপযুক্ত লাইব্রেরি ব্যবহার করুন, উদাহরণস্বরূপ Node.js-এ ua-parser-js লাইব্রেরি। ব্যবহারকারী এজেন্ট সনাক্তকরণ পরিচালনা করার জন্য একটি লাইব্রেরি খোঁজার পরামর্শ দেওয়া হয় কারণ আপনি সম্ভবত সেই নিয়মিত অভিব্যক্তিগুলি নিজে লিখতে চান না।

এই পদ্ধতির সুবিধা হল যে এটি শুধুমাত্র কুকি সেট করার সময়ে একটি পরিবর্তন করতে হবে। যাইহোক, এখানে প্রয়োজনীয় সতর্কতা হল যে ব্যবহারকারী এজেন্ট স্নিফিং সহজাতভাবে ভঙ্গুর এবং সমস্ত প্রভাবিত ব্যবহারকারীদের ধরতে পারে না।

SameSite=None ভাষা, লাইব্রেরি এবং ফ্রেমওয়ার্কের জন্য সমর্থন

বেশিরভাগ ভাষা এবং লাইব্রেরি কুকিজের জন্য SameSite অ্যাট্রিবিউটকে সমর্থন করে, তবে SameSite=None যোগ করা এখনও তুলনামূলকভাবে নতুন নয় যার মানে হল যে আপনাকে আপাতত কিছু মানক আচরণের চারপাশে কাজ করতে হবে। এগুলি GitHub-এ SameSite উদাহরণ রেপোতে নথিভুক্ত করা হয়েছে।

সাহায্য পাচ্ছেন

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