SameSite কুকি ব্যাখ্যা করা হয়েছে

Rowan Merewood

প্রতিটি কুকিতে একটি কী-ভ্যালু পেয়ারের পাশাপাশি বেশ কিছু অ্যাট্রিবিউট থাকে, যেগুলো নিয়ন্ত্রণ করে সেই কুকিটি কখন এবং কোথায় ব্যবহৃত হবে।

SameSite অ্যাট্রিবিউটের (যা RFC6265bis- এ সংজ্ঞায়িত) প্রবর্তনের ফলে আপনি নির্ধারণ করতে পারেন যে আপনার কুকিটি ফার্স্ট-পার্টি নাকি সেম-সাইট প্রেক্ষাপটে সীমাবদ্ধ থাকবে। এখানে 'সাইট' বলতে ঠিক কী বোঝানো হচ্ছে, তা বোঝা সহায়ক। সাইট হলো ডোমেইন সাফিক্স এবং তার ঠিক আগের অংশের সমন্বয়। উদাহরণস্বরূপ, www.web.dev ডোমেইনটি web.dev সাইটের একটি অংশ।

মূল পরিভাষা: যদি ব্যবহারকারী www.web.dev এ থেকে static.web.dev থেকে কোনো ছবির জন্য অনুরোধ করেন, তাহলে সেটি একটি সেম-সাইট রিকোয়েস্ট।

পাবলিক সাফিক্স লিস্ট নির্ধারণ করে কোন পেজগুলোকে একই সাইটের অংশ হিসেবে গণ্য করা হবে। এটি শুধু .com মতো টপ-লেভেল ডোমেইনের উপরই নির্ভর করে না, বরং github.io মতো সার্ভিসগুলোকেও অন্তর্ভুক্ত করতে পারে। এর ফলে your-project.github.io এবং my-project.github.io আলাদা সাইট হিসেবে গণ্য করা যায়।

মূল বিষয়: যদি ব্যবহারকারী your-project.github.io তে থেকে my-project.github.io থেকে কোনো ছবির জন্য অনুরোধ করেন, তবে সেটি একটি ক্রস-সাইট অনুরোধ।

কুকি ব্যবহার ঘোষণা করতে SameSite অ্যাট্রিবিউট ব্যবহার করুন।

কুকির SameSite অ্যাট্রিবিউটটি এই আচরণ নিয়ন্ত্রণ করার জন্য তিনটি ভিন্ন উপায় প্রদান করে। আপনি অ্যাট্রিবিউটটি উল্লেখ না করার সিদ্ধান্ত নিতে পারেন, অথবা কুকিটিকে শুধুমাত্র একই-সাইটের অনুরোধের মধ্যে সীমাবদ্ধ রাখতে Strict বা Lax ব্যবহার করতে পারেন।

আপনি যদি SameSite কে Strict এ সেট করেন, তাহলে আপনার কুকি শুধুমাত্র একটি ফার্স্ট-পার্টি প্রেক্ষাপটে পাঠানো যাবে; অর্থাৎ, যদি কুকিটির জন্য নির্ধারিত সাইটটি ব্রাউজারের অ্যাড্রেস বারে দেখানো সাইটের সাথে মিলে যায়। সুতরাং, যদি promo_shown কুকিটি নিম্নরূপে সেট করা থাকে:

Set-Cookie: promo_shown=1; SameSite=Strict

যখন ব্যবহারকারী আপনার সাইটে আসেন, তখন প্রত্যাশা অনুযায়ী অনুরোধের সাথে কুকিটি পাঠানো হয়। তবে, যদি ব্যবহারকারী অন্য কোনো সাইট থেকে কোনো লিঙ্কের মাধ্যমে আপনার সাইটে আসেন, তাহলে সেই প্রাথমিক অনুরোধে কুকিটি পাঠানো হয় না। এটি সেইসব ফিচারের সাথে সম্পর্কিত কুকির জন্য ভালো, যেগুলো প্রাথমিক নেভিগেশনের আড়ালে থাকে, যেমন পাসওয়ার্ড পরিবর্তন করা বা কেনাকাটা করা। কিন্তু promo_shown মতো কুকির জন্য এটি খুবই সীমাবদ্ধ। আপনার পাঠক যদি লিঙ্কের মাধ্যমে সাইটে প্রবেশ করেন, তাহলে তারা চাইবেন যেন কুকিটি পাঠানো হয়, যাতে তাদের পছন্দটি প্রয়োগ করা যায়।

SameSite=Lax ব্রাউজারকে এই শীর্ষ-স্তরের নেভিগেশনগুলির সাথে কুকি পাঠাতে অনুমতি দেয়। উদাহরণস্বরূপ, যদি অন্য কোনো সাইট আপনার সাইটের বিষয়বস্তুকে রেফারেন্স করে, এক্ষেত্রে আপনার বিড়ালের ছবি ব্যবহার করে এবং আপনার আর্টিকেলের একটি লিঙ্ক নিম্নরূপভাবে প্রদান করে:

<p>Look at this amazing cat!</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>

একটি কুকি নিম্নরূপভাবে Lax -এ সেট করা থাকলে:

Set-Cookie: promo_shown=1; SameSite=Lax

যখন ব্রাউজার অন্য ব্যক্তির ব্লগের জন্য amazing-cat.png অনুরোধ করে, তখন আপনার সাইট কুকি পাঠায় না। তবে, যখন পাঠক আপনার সাইটে cat.html এর লিঙ্কে ক্লিক করেন, তখন সেই অনুরোধে কুকি অন্তর্ভুক্ত থাকে।

আমরা SameSite এইভাবে ব্যবহার করার পরামর্শ দিই, যেখানে ওয়েবসাইট প্রদর্শনে প্রভাব ফেলে এমন কুকিগুলোকে Lax এবং ব্যবহারকারীর কার্যকলাপ সম্পর্কিত কুকিগুলোকে Strict হিসেবে সেট করা হয়।

আপনি SameSite None এ সেট করে এটাও বোঝাতে পারেন যে আপনি চান কুকিটি সব ক্ষেত্রেই পাঠানো হোক। আপনি যদি এমন কোনো পরিষেবা প্রদান করেন যা অন্যান্য সাইট ব্যবহার করে, যেমন উইজেট, এমবেডেড কন্টেন্ট, অ্যাফিলিয়েট প্রোগ্রাম, বিজ্ঞাপন, বা একাধিক সাইটে সাইন-ইন, তাহলে আপনার উদ্দেশ্য পরিষ্কার রাখতে None ব্যবহার করুন।

SameSite ছাড়া ডিফল্ট আচরণে পরিবর্তন

SameSite অ্যাট্রিবিউটটি ব্যাপকভাবে সমর্থিত হলেও, এটি ব্যাপকভাবে গৃহীত হয়নি। অতীতে, SameSite ছাড়া কুকি সেট করলে তা ডিফল্টভাবে সব ক্ষেত্রেই পাঠানো হতো, যা ব্যবহারকারীদের CSRF এবং অনিচ্ছাকৃত তথ্য ফাঁসের ঝুঁকিতে ফেলে দিত। ডেভেলপারদের তাদের উদ্দেশ্য স্পষ্টভাবে জানাতে উৎসাহিত করতে এবং ব্যবহারকারীদের একটি নিরাপদ অভিজ্ঞতা প্রদান করতে, IETF-এর প্রস্তাবনা ‘Incrementally Better Cookies’- এ দুটি মূল পরিবর্তনের কথা বলা হয়েছে:

• যেসব কুকিতে SameSite অ্যাট্রিবিউট নেই, সেগুলোকে SameSite=Lax হিসেবে গণ্য করা হয়।
• SameSite=None যুক্ত কুকিগুলিতে অবশ্যই Secure উল্লেখ করতে হবে, যার অর্থ হলো সেগুলির জন্য একটি সুরক্ষিত প্রেক্ষাপট প্রয়োজন।

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

ডিফল্টরূপে SameSite=Lax

আপনি যদি কোনো কুকির SameSite অ্যাট্রিবিউট উল্লেখ না করে সেটি পাঠান, তাহলে ব্রাউজার সেই কুকিটিকে এমনভাবে বিবেচনা করে যেন সেটির সেটিং SameSite=Lax করা আছে। তবুও, বিভিন্ন ব্রাউজারে আপনার ব্যবহারকারীর অভিজ্ঞতা আরও সামঞ্জস্যপূর্ণ করতে আমরা স্পষ্টভাবে SameSite=Lax সেট করার পরামর্শ দিই।

SameSite=None অবশ্যই সুরক্ষিত হতে হবে

যখন আপনি SameSite=None ব্যবহার করে ক্রস-সাইট কুকি তৈরি করেন, তখন ব্রাউজারের গ্রহণের জন্য আপনাকে অবশ্যই সেগুলোকে Secure এ সেট করতে হবে:

Set-Cookie: widget_session=abc123; SameSite=None; Secure

Chrome 76 থেকে about://flags/#cookies-without-same-site-must-be-secure সক্রিয় করে, এবং Firefox 69 থেকে about:config এ network.cookie.sameSite.noneRequiresSecure সেট করে আপনি এই আচরণটি পরীক্ষা করতে পারেন।

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

SameSite কুকি রেসিপি

SameSite=None এর এই পরিবর্তনগুলো এবং ব্রাউজারের আচরণের পার্থক্যগুলো সফলভাবে সামাল দেওয়ার জন্য আপনার কুকি আপডেট করার বিষয়ে আরও বিস্তারিত জানতে, পরবর্তী আর্টিকেল, SameSite cookie recipes দেখুন।

লিলি চেন, মাল্টে উবল, মাইক ওয়েস্ট, রব ডডসন, টম স্টেইনার এবং বিবেক শেখরের অবদান ও মতামতের জন্য আন্তরিক ধন্যবাদ।

আনস্প্ল্যাশে পিলে-রিন প্রিসকের কুকি হিরো ছবি