Chrome তৃতীয় পক্ষের কুকিগুলির সাথে ব্যবহারকারীর পছন্দের জন্য একটি নতুন অভিজ্ঞতার প্রস্তাব করছে৷ তৃতীয় পক্ষের কুকিজ ছাড়াই ব্রাউজ করা বেছে নেওয়া ব্যবহারকারীদের জন্য আপনাকে আপনার সাইট প্রস্তুত করতে হবে।
এই পৃষ্ঠায় আপনি সবচেয়ে বেশি প্রভাবিত হতে পারে এমন পরিচয় পরিস্থিতির তথ্য পাবেন, সেইসাথে সম্ভাব্য সমাধানের উল্লেখও পাবেন।
যদি আপনার ওয়েবসাইট শুধুমাত্র একই ডোমেন এবং সাবডোমেনের মধ্যে প্রবাহ পরিচালনা করে, যেমন publisher.example এবং login.publisher.example , তাহলে এটি ক্রস-সাইট কুকিজ ব্যবহার করবে না এবং আপনার সাইন-ইন প্রবাহ তৃতীয়- দ্বারা প্রভাবিত হবে বলে আশা করা যায় না। পার্টি কুকি পরিবর্তন.
যাইহোক, যদি আপনার সাইট লগইন করার জন্য একটি পৃথক ডোমেন ব্যবহার করে, যেমন Google সাইন-ইন বা Facebook লগইন এর সাথে, অথবা আপনার সাইটটিকে একাধিক ডোমেন বা সাবডোমেন জুড়ে ব্যবহারকারীর প্রমাণীকরণ ভাগ করতে হয়, তাহলে আপনাকে আপনার সাইটে পরিবর্তন করতে হবে। ক্রস-সাইট কুকিজ থেকে দূরে একটি মসৃণ রূপান্তর নিশ্চিত করুন।
সাধারণ ব্যবহারকারীর যাত্রা
ঐতিহাসিকভাবে, অনেক পরিচয় কর্মপ্রবাহ তৃতীয় পক্ষের কুকির উপর নির্ভর করে। এই সারণীতে কিছু সাধারণ ব্যবহারকারীর যাত্রা এবং সম্ভাব্য সমাধানের তালিকা রয়েছে যা তৃতীয় পক্ষের কুকির উপর নির্ভর করে না। নিম্নলিখিত বিভাগগুলি এই সুপারিশগুলির যুক্তি ব্যাখ্যা করবে।
সাধারণ ব্যবহারের ক্ষেত্রে প্রস্তাবিত বিকল্প APIs
| ব্যবহারকারীর যাত্রা | প্রস্তাবিত API |
|---|---|
| সামাজিক সাইন-ইন | পরিচয় প্রদানকারীদের জন্য: FedCM প্রয়োগ করুন নির্ভরশীল পক্ষগুলির জন্য: আপনার পরিচয় প্রদানকারীর সাথে যোগাযোগ করুন |
| ফ্রন্ট চ্যানেল লগআউট | পরিচয় প্রদানকারীদের জন্য: FedCM প্রয়োগ করুন |
পরিচয় প্রদানকারী বা কাস্টম সমাধানের জন্য: সম্পর্কিত ওয়েবসাইট সেট | |
| ব্যবহারকারীর প্রোফাইল পরিচালনা | স্টোরেজ অ্যাক্সেস API সম্পর্কিত ওয়েবসাইট সেট চিপস FedCM + SAA |
| স্টোরেজ অ্যাক্সেস API সম্পর্কিত ওয়েবসাইট সেট চিপস FedCM + SAA | |
| প্রমাণীকরণ | স্টোরেজ অ্যাক্সেস API ফেডসিএম ওয়েব প্রমাণীকরণ API science পার্টিশনড পপিনস |
| এই পরিস্থিতিতে সাধারণত তৃতীয় পক্ষের কুকি নির্ভরতা থাকে না এবং প্রভাবিত হওয়ার আশা করা হয় না। |
আপনার পরিচয়-সম্পর্কিত ব্যবহারকারীর যাত্রা পরীক্ষা করুন
আপনার সাইন-ইন প্রবাহ তৃতীয় পক্ষের কুকি পরিবর্তনের দ্বারা প্রভাবিত হয়েছে কিনা তা পরীক্ষা করার সর্বোত্তম উপায় হল আপনার নিবন্ধন, পাসওয়ার্ড পুনরুদ্ধার, সাইন-ইন এবং সাইন-আউট প্রবাহের মাধ্যমে তৃতীয় পক্ষের কুকি পরীক্ষার পতাকা সক্ষম করা ।
আপনি তৃতীয় পক্ষের কুকি সীমাবদ্ধ করার পরে এটি পরীক্ষা করার জন্য জিনিসগুলির একটি চেকলিস্ট:
- ব্যবহারকারী নিবন্ধন: একটি নতুন অ্যাকাউন্ট তৈরি করা প্রত্যাশা অনুযায়ী কাজ করে। যদি তৃতীয় পক্ষের পরিচয় প্রদানকারী ব্যবহার করে থাকেন, তাহলে পরীক্ষা করুন যে নতুন অ্যাকাউন্টের নিবন্ধন প্রতিটি ইন্টিগ্রেশনের জন্য কাজ করে।
- পাসওয়ার্ড পুনরুদ্ধার: পাসওয়ার্ড পুনরুদ্ধার আশানুরূপ কাজ করে, ওয়েব UI থেকে, ক্যাপচা, পাসওয়ার্ড পুনরুদ্ধারের ইমেল গ্রহণ করা পর্যন্ত।
- সাইন-ইন: সাইন-ইন ওয়ার্কফ্লো একই ডোমেনের মধ্যে কাজ করে এবং অন্য ডোমেনে নেভিগেট করার সময়। প্রতিটি সাইন-ইন ইন্টিগ্রেশন পরীক্ষা করতে মনে রাখবেন।
- সাইন-আউট: সাইন-আউট প্রক্রিয়া প্রত্যাশিতভাবে কাজ করে এবং ব্যবহারকারী সাইন-আউট প্রবাহের পরে সাইন-আউট থেকে যায়।
এছাড়াও আপনার পরীক্ষা করা উচিত যে অন্যান্য সাইটের বৈশিষ্ট্যগুলির জন্য ব্যবহারকারীর সাইন-ইন প্রয়োজন সেগুলি ক্রস-সাইট কুকি ছাড়াই কার্যকর থাকে, বিশেষ করে যদি সেগুলি ক্রস-সাইট সংস্থানগুলি লোড করা জড়িত থাকে৷ উদাহরণস্বরূপ, আপনি যদি ব্যবহারকারীর প্রোফাইল ছবি লোড করার জন্য একটি 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) সম্পর্কিত উত্সগুলির একটি সীমিত সেট নিবন্ধন করতে দেয় যা জুড়ে শংসাপত্র তৈরি এবং ব্যবহার করা যেতে পারে।
- আপনি যদি 5টিরও বেশি সংশ্লিষ্ট ডোমেন জুড়ে ব্যবহারকারীদের প্রমাণীকরণ করেন, ফেডারেটেড ক্রেডেনশিয়াল ম্যানেজমেন্ট (FedCM) অন্বেষণ করুন : FedCM পরিচয় প্রদানকারীকে তৃতীয়-পক্ষ কুকির প্রয়োজন ছাড়াই পরিচয়-সম্পর্কিত প্রবাহ পরিচালনা করতে Chrome-এর উপর নির্ভর করতে সক্ষম করে। আপনার ক্ষেত্রে, আপনার "সাইন-ইন ডোমেন" FedCM পরিচয় প্রদানকারী হিসাবে কাজ করতে পারে এবং আপনার অন্যান্য ডোমেন জুড়ে ব্যবহারকারীদের প্রমাণীকরণ করতে ব্যবহার করা যেতে পারে।
এম্বেড থেকে প্রমাণীকরণ
ধরুন একটি 3-party-app.example iframe 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 iframe পার্টিশন করা হয়েছে এবং 3-party-app.example এ প্রথম-পক্ষের প্রসঙ্গে সেট করা কুকি অ্যাক্সেস করতে পারে না।
The same problem would occur when a user is redirected from top-level.example to 3-party-app.example and back. কুকিটি 3-party-app.example সাইটের প্রথম-পক্ষের প্রেক্ষাপটে লেখা, কিন্তু এটি বিভাজিত এবং 3-party-app.example iframe-এর মধ্যে অ্যাক্সেসযোগ্য নয়।
যে ক্ষেত্রে ব্যবহারকারী একটি উচ্চ-স্তরের প্রেক্ষাপটে এমবেডেড মূল পরিদর্শন করেছেন, স্টোরেজ অ্যাক্সেস API একটি ভাল সমাধান।
তৃতীয় পক্ষের কুকিজগুলির উপর নির্ভর করে এমন সমাধানগুলি থেকে দূরে সরে যেতে, আমরা সুপারিশ করি যে পরিচয় প্রদানকারীরা FedCM API গ্রহণ করে এবং FedCM পপ-আপগুলির পরিবর্তে ভিতরের এম্বেডগুলি থেকে কল করা হয়৷
এই প্রবাহের জন্য আরেকটি প্রস্তাবিত সমাধান, পার্টিশনড পপিনস , বাস্তবায়নাধীন।
সামাজিক সাইন-ইন
গুগল , ফেসবুক লগইন এবং টুইটারের সাথে লগ ইন করার মতো সাইন-ইন বোতামগুলি একটি নির্দিষ্ট চিহ্ন যা আপনার ওয়েবসাইটটি একটি ফেডারেটেড পরিচয় সরবরাহকারী ব্যবহার করছে। প্রতিটি ফেডারেটেড পরিচয় প্রদানকারীর নিজস্ব বাস্তবায়ন থাকবে।
আপনি যদি অপ্রচলিত Google সাইন-ইন জাভাস্ক্রিপ্ট প্ল্যাটফর্ম লাইব্রেরি ব্যবহার করেন, তাহলে প্রমাণীকরণ এবং অনুমোদনের জন্য আপনি কীভাবে নতুন Google আইডেন্টিটি পরিষেবা লাইব্রেরিতে স্থানান্তর করবেন সে সম্পর্কে তথ্য পেতে পারেন৷
নতুন Google আইডেন্টিটি সার্ভিসেস লাইব্রেরি ব্যবহার করে বেশিরভাগ সাইট থার্ড-পার্টি কুকিজের উপর নির্ভরতা সরিয়ে ফেলেছে, কারণ লাইব্রেরিটি সামঞ্জস্যের জন্য FedCM ব্যবহার করার জন্য নীরবে মাইগ্রেট করবে। আমরা আপনার সাইটকে তৃতীয় পক্ষের কুকি ফেজআউট টেস্টিং ফ্ল্যাগ সক্ষম করে পরীক্ষা করার পরামর্শ দিই এবং প্রয়োজনে FedCM মাইগ্রেশন চেকলিস্ট প্রস্তুত করতে ব্যবহার করুন।
এম্বেড থেকে ব্যবহারকারীর ডেটা অ্যাক্সেস এবং সংশোধন করুন
এম্বেড করা সামগ্রী প্রায়শই ব্যবহারকারীর যাত্রার জন্য ব্যবহার করা হয় যেমন ব্যবহারকারীর প্রোফাইল বা সদস্যতা ডেটা অ্যাক্সেস করা বা পরিচালনা করা।
উদাহরণস্বরূপ, একজন ব্যবহারকারী website.example এ লগইন করতে পারে, যা একটি subscriptions.example উইজেট এম্বেড করে। এই উইজেটটি ব্যবহারকারীদের তাদের ডেটা পরিচালনা করতে দেয়, যেমন প্রিমিয়াম সামগ্রীতে সদস্যতা নেওয়া বা বিলিং তথ্য আপডেট করা। ব্যবহারকারীর ডেটা পরিবর্তন করার জন্য, এম্বেড করা উইজেটকে website.example এ এমবেড করার সময় তার নিজস্ব কুকিজ অ্যাক্সেস করতে হতে পারে। দৃশ্যপটে যেখানে এই ডেটাটিকে website.example এ বিচ্ছিন্ন করা উচিত, চিপস এটি নিশ্চিত করতে সাহায্য করতে পারে যে এম্বেডটি তার প্রয়োজনীয় তথ্য অ্যাক্সেস করতে পারে৷ CHIPS-এর সাথে, website.example এ এমবেড করা subscriptions.example উইজেট অন্যান্য ওয়েবসাইটে ব্যবহারকারীর সাবস্ক্রিপশন ডেটা অ্যাক্সেস করতে পারবে না।
আরেকটি ক্ষেত্রে বিবেচনা করুন: streaming.example থেকে একটি ভিডিও website.example এ এমবেড করা হয়েছে এবং ব্যবহারকারীর একটি প্রিমিয়াম streaming.example সাবস্ক্রিপশন রয়েছে, যা বিজ্ঞাপনগুলি অক্ষম করার জন্য উইজেটকে জানতে হবে৷ একই কুকি একাধিক সাইট জুড়ে অ্যাক্সেস করার প্রয়োজন হলে, যদি ব্যবহারকারী পূর্বে streaming.example একটি শীর্ষ-স্তরের হিসাবে পরিদর্শন করে থাকে তবে Storage Access API ব্যবহার করার কথা বিবেচনা করুন এবং যদি website.example এর সেটটি streaming.example এর মালিক হয় তাহলে সম্পর্কিত ওয়েবসাইট সেটগুলি ।
ক্রোম 131 থেকে, FedCM স্টোরেজ অ্যাক্সেস API এর সাথে একীভূত । এই ইন্টিগ্রেশনের মাধ্যমে, ব্যবহারকারী যখন FedCM প্রম্পট গ্রহণ করে, ব্রাউজারটি IdP-কে অ-বিভাগহীন সঞ্চয়স্থানে এম্বেড অ্যাক্সেস প্রদান করবে।
For more information on which API to choose to handle a particular user journey with embedded content, check the Embeds guide .
ফ্রন্ট-চ্যানেল লগআউট
ফ্রন্ট-চ্যানেল লগআউট হল এমন একটি প্রক্রিয়া যা ব্যবহারকারীকে একটি পরিষেবায় লগ আউট করার সময় সমস্ত সম্পর্কিত অ্যাপগুলি থেকে লগ আউট করার অনুমতি দেয়৷ OIDC-এর ফ্রন্ট-চ্যানেল লগআউটের জন্য IdP-কে বেশ কিছু নির্ভরশীল পার্টি (RP) iframes এম্বেড করতে হবে যা RP-এর কুকিজের উপর নির্ভর করে।
যদি আপনার সমাধান একটি পরিচয় প্রদানকারীর উপর নির্ভর করে, ছোটখাটো পরিবর্তন (যেমন একটি লাইব্রেরি আপগ্রেড) প্রয়োজন হতে পারে। আরও নির্দেশনার জন্য, আপনার পরিচয় প্রদানকারীর সাথে যোগাযোগ করুন।
এই ব্যবহারের ক্ষেত্রে, FedCM logoutRPs বৈশিষ্ট্যের সাথে পরীক্ষা করেছে। এটি আইডিপিকে যেকোন RP লগ আউট করার অনুমতি দেয় যার জন্য ব্যবহারকারী পূর্বে RP-IdP যোগাযোগ অনুমোদন করেছে। এই বৈশিষ্ট্যটি আর উপলব্ধ নেই, তবে আমরা আপনাকে প্রাথমিক প্রস্তাবটি দেখার জন্য উত্সাহিত করি এবং যদি আপনি এই বৈশিষ্ট্যটিতে আগ্রহী হন বা আপনার প্রয়োজন হয় তবে আপনার প্রতিক্রিয়া আমাদের সাথে ভাগ করুন৷
অন্যান্য ব্যবহারকারীর যাত্রা
থার্ড-পার্টি কুকিজের উপর নির্ভর করে না এমন ব্যবহারকারীর যাত্রা Chrome কীভাবে তৃতীয় পক্ষের কুকিগুলি পরিচালনা করে তার পরিবর্তন দ্বারা প্রভাবিত হওয়া উচিত নয়। বিদ্যমান সমাধান, যেমন সাইন ইন, সাইন আউট, বা প্রথম পক্ষের প্রেক্ষাপটে অ্যাকাউন্ট পুনরুদ্ধার, 2FA, উদ্দেশ্য অনুযায়ী কাজ করা উচিত। ভাঙ্গনের সম্ভাব্য পয়েন্টগুলি আগে বর্ণনা করা হয়েছে। একটি নির্দিষ্ট API সম্পর্কে আরও তথ্যের জন্য, API স্থিতি পৃষ্ঠাটি দেখুন। কোনো বিচ্ছেদের অভিজ্ঞতা goo.gle/report-3pc-broken- এ রিপোর্ট করুন। এছাড়াও আপনি একটি প্রতিক্রিয়া ফর্ম জমা দিতে পারেন বা গোপনীয়তা স্যান্ডবক্স বিকাশকারী সমর্থন সংগ্রহস্থলে GitHub-এ একটি সমস্যা ফাইল করতে পারেন।
আপনার সাইট অডিট করুন
যদি আপনার ওয়েবসাইটটি এই গাইডে বর্ণিত ব্যবহারকারী ভ্রমণগুলির মধ্যে একটি প্রয়োগ করে তবে আপনার সাইটগুলি প্রস্তুত রয়েছে তা নিশ্চিত করা দরকার: তৃতীয় পক্ষের কুকি ব্যবহারের জন্য আপনার সাইটটি নিরীক্ষণ, ভাঙ্গনের জন্য পরীক্ষা এবং প্রস্তাবিত সমাধানগুলিতে স্থানান্তরিত করুন।