আপনার সাইন-ইন ওয়ার্কফ্লোতে তৃতীয় পক্ষের কুকি পরিবর্তনের প্রভাব পরীক্ষা করুন

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

তৃতীয় পক্ষের কুকিজ উপলব্ধ থাকুক বা না থাকুক, আপনার সমস্ত ব্যবহারকারীদের জন্য একটি দুর্দান্ত অভিজ্ঞতা প্রদানের জন্য আপনার সাইট বা পরিষেবার প্রয়োজন।

এই পৃষ্ঠায় আপনি সম্ভাব্য সম্ভাব্য সনাক্তকরণ পরিস্থিতি সম্পর্কে তথ্য পাবেন, পাশাপাশি সম্ভাব্য সমাধানের উল্লেখও পাবেন।

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

তবে, যদি আপনার সাইট লগইনের জন্য আলাদা ডোমেন ব্যবহার করে, যেমন Google সাইন-ইন বা Facebook লগইন , অথবা আপনার সাইটের একাধিক ডোমেন বা সাবডোমেন জুড়ে ব্যবহারকারীর প্রমাণীকরণ ভাগ করে নেওয়ার প্রয়োজন হয়, তাহলে ক্রস-সাইট কুকিজ থেকে দূরে সরে যাওয়ার জন্য আপনার সাইটে পরিবর্তন করার সম্ভাবনা রয়েছে।

সাধারণ ব্যবহারকারীর ভ্রমণ

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

সাধারণ ব্যবহারের ক্ষেত্রে প্রস্তাবিত বিকল্প API গুলি

টেবিলে থাকা তথ্যগুলি তাদের বিকাশের প্রাথমিক পর্যায়ে রয়েছে। আপনার প্রতিক্রিয়া মূল্যবান এবং তাদের ভবিষ্যত গঠনে সহায়তা করবে। এই API গুলি সম্পর্কে আপনার মতামত জানান: পার্টিশনেড পপিনস ।

আপনার পরিচয়-সম্পর্কিত ব্যবহারকারীর ভ্রমণ পরীক্ষা করুন

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

তৃতীয় পক্ষের কুকিজ সীমাবদ্ধ করার পরে যে বিষয়গুলি পরীক্ষা করতে হবে তার একটি তালিকা এখানে দেওয়া হল:

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

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

সাইন-ইন সমাধান

এই বিভাগে, আপনি কীভাবে এই প্রবাহগুলিকে প্রভাবিত করতে পারে সে সম্পর্কে আরও সুনির্দিষ্ট তথ্য পাবেন।

তৃতীয় পক্ষের একক সাইন অন (SSO)

থার্ড-পার্টি সিঙ্গেল সাইন-ইন (SSO) একজন ব্যবহারকারীকে একটি প্ল্যাটফর্মে একক শংসাপত্রের মাধ্যমে প্রমাণীকরণ করতে দেয়, তারপর তাদের লগইন তথ্য পুনরায় প্রবেশ না করেই একাধিক অ্যাপ্লিকেশন এবং ওয়েবসাইট অ্যাক্সেস করতে দেয়। SSO সমাধান বাস্তবায়নের জটিলতার কারণে, অনেক কোম্পানি একাধিক উৎসের মধ্যে সাইন-ইন অবস্থা ভাগ করে নেওয়ার জন্য একটি তৃতীয় পক্ষের সমাধান প্রদানকারী ব্যবহার করে। প্রদানকারীদের উদাহরণগুলির মধ্যে রয়েছে Okta, Ping Identity, Google Cloud IAM অথবা Microsoft Entra ID।

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

একাধিক ডোমেন

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

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

এই পরিস্থিতিতে সম্ভাব্য মাইগ্রেশন পাথগুলি হল:

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

এম্বেড থেকে প্রমাণীকরণ

ধরুন একটি 3-party-app.example আইফ্রেম top-level.example এ এমবেড করা আছে। 3-party-app.example এ, ব্যবহারকারী 3-party-app.example শংসাপত্র দিয়ে অথবা অন্য কোনও তৃতীয় পক্ষের সরবরাহকারীর সাথে লগইন করতে পারেন।

ব্যবহারকারী "লগইন" এ ক্লিক করে, এবং 3-party-app.example পপ-আপের মধ্যে প্রমাণীকরণ করে। 3-party-app.example পপ-আপ একটি প্রথম-পক্ষের কুকি সেট করে। তবে, top-level.example এ এমবেড করা 3-party-app.example আইফ্রেমটি পার্টিশন করা হয়েছে এবং 3-party-app.example এ প্রথম-পক্ষের প্রসঙ্গে সেট করা কুকি অ্যাক্সেস করতে পারে না।

একই সমস্যা তখনও দেখা দেবে যখন একজন ব্যবহারকারীকে top-level.example থেকে 3-party-app.example এ পুনঃনির্দেশিত করা হবে এবং আবার ফিরে আসবে। কুকিটি 3-party-app.example সাইটের প্রথম-পক্ষের প্রসঙ্গে লেখা আছে, কিন্তু এটি বিভাজিত এবং 3-party-app.example iframe এর মধ্যে অ্যাক্সেসযোগ্য নয়।

যেসব ক্ষেত্রে ব্যবহারকারী উচ্চ-স্তরের প্রেক্ষাপটে এমবেডেড অরিজিন পরিদর্শন করেছেন, সেখানে স্টোরেজ অ্যাক্সেস API একটি ভালো সমাধান।

তৃতীয় পক্ষের কুকিজের উপর নির্ভরশীল সমাধানগুলি থেকে দূরে সরে যাওয়ার জন্য, আমরা পরিচয় প্রদানকারীদের FedCM API গ্রহণ করার পরামর্শ দিচ্ছি এবং FedCM পপ-আপের পরিবর্তে ভিতরের এম্বেড থেকে ডাকা হয়।

এই প্রবাহের জন্য আরেকটি প্রস্তাবিত সমাধান, পার্টিশনড পপিন্স , বাস্তবায়নের অধীনে রয়েছে।

সামাজিক সাইন-ইন

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

আপনি যদি অবচিত Google সাইন-ইন জাভাস্ক্রিপ্ট প্ল্যাটফর্ম লাইব্রেরি ব্যবহার করেন, তাহলে প্রমাণীকরণ এবং অনুমোদনের জন্য নতুন Google পরিচয় পরিষেবা লাইব্রেরিতে কীভাবে স্থানান্তর করবেন সে সম্পর্কে তথ্য পেতে পারেন।

নতুন Google Identity Services লাইব্রেরি ব্যবহারকারী বেশিরভাগ সাইটই তৃতীয় পক্ষের কুকির উপর নির্ভরতা সরিয়ে নিয়েছে, কারণ লাইব্রেরিটি সামঞ্জস্যের জন্য নীরবে FedCM ব্যবহারে স্থানান্তরিত হবে। আমরা সুপারিশ করছি যে আপনি তৃতীয় পক্ষের কুকি ফেজআউট টেস্টিং ফ্ল্যাগ সক্ষম করে আপনার সাইটটি পরীক্ষা করুন এবং প্রয়োজনে, FedCM মাইগ্রেশন চেকলিস্ট ব্যবহার করে প্রস্তুতি নিন।

এম্বেড থেকে ব্যবহারকারীর ডেটা অ্যাক্সেস এবং সংশোধন করুন

ব্যবহারকারীর প্রোফাইল বা সাবস্ক্রিপশন ডেটা অ্যাক্সেস বা পরিচালনা করার মতো ব্যবহারকারীর ভ্রমণের জন্য প্রায়শই এমবেডেড কন্টেন্ট ব্যবহার করা হয়।

উদাহরণস্বরূপ, একজন ব্যবহারকারী website.example এ লগইন করতে পারেন, যা একটি subscriptions.example উইজেট এম্বেড করে। এই উইজেট ব্যবহারকারীদের তাদের ডেটা পরিচালনা করতে দেয়, যেমন প্রিমিয়াম কন্টেন্ট সাবস্ক্রাইব করা বা বিলিং তথ্য আপডেট করা। ব্যবহারকারীর ডেটা পরিবর্তন করার জন্য, website.example এ এমবেড করা অবস্থায় এমবেড করা উইজেটকে তার নিজস্ব কুকিজ অ্যাক্সেস করতে হতে পারে। যে পরিস্থিতিতে এই ডেটা website.example এ আলাদা করা উচিত, CHIPS নিশ্চিত করতে সাহায্য করতে পারে যে এম্বেডটি তার প্রয়োজনীয় তথ্য অ্যাক্সেস করতে পারে। CHIPS এর সাহায্যে, website.example এ এমবেড করা subscriptions.example উইজেট অন্যান্য ওয়েবসাইটের ব্যবহারকারীর সাবস্ক্রিপশন ডেটাতে অ্যাক্সেস পাবে না।

আরেকটি ঘটনা বিবেচনা করুন: streaming.example থেকে একটি ভিডিও website.example এ এমবেড করা আছে, এবং ব্যবহারকারীর একটি প্রিমিয়াম streaming.example সাবস্ক্রিপশন আছে, যা বিজ্ঞাপন বন্ধ করার জন্য উইজেটকে জানাতে হবে। যদি একই কুকি একাধিক সাইটে অ্যাক্সেস করার প্রয়োজন হয়, তাহলে ব্যবহারকারী যদি আগে streaming.example কে শীর্ষ-স্তরের হিসাবে দেখে থাকেন তবে Storage Access API ব্যবহার করার কথা বিবেচনা করুন, এবং যদি website.example এর সেট streaming.example এর মালিক হয় তবে Related Website Sets ব্যবহার করার কথা বিবেচনা করুন।

Chrome 131 থেকে, FedCM স্টোরেজ অ্যাক্সেস API এর সাথে একীভূত হয়। এই একীভূতকরণের মাধ্যমে, ব্যবহারকারী যখন FedCM প্রম্পট গ্রহণ করে, তখন ব্রাউজারটি IdP কে পার্টিশনবিহীন স্টোরেজে এম্বেড অ্যাক্সেস প্রদান করবে।

এমবেডেড কন্টেন্ট সহ একটি নির্দিষ্ট ব্যবহারকারীর যাত্রা পরিচালনা করার জন্য কোন API বেছে নেবেন সে সম্পর্কে আরও তথ্যের জন্য, এমবেডস নির্দেশিকাটি দেখুন।

অন্যান্য ব্যবহারকারীর ভ্রমণ

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

আপনার সাইটটি অডিট করুন

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