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

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

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

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

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

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

  • 51
  • 16
  • 60
  • 13

উৎস

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

একটি প্ল্যাটফর্ম-নির্দিষ্ট অ্যাপের একটি WebView একটি ব্রাউজার দ্বারা চালিত হয়। ডেভেলপারদের পরীক্ষা করতে হবে যে তাদের অ্যাপগুলিকে প্রভাবিত করে এমন বিধিনিষেধ বা সমস্যাগুলি তাদের অ্যাপের ওয়েবভিউতেও প্রযোজ্য কিনা।

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 উদাহরণ সংগ্রহস্থলে নথিভুক্ত করা হয়েছে।

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

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