Chrome তৃতীয় পক্ষের কুকিগুলির সাথে ব্যবহারকারীর পছন্দের জন্য একটি নতুন অভিজ্ঞতার প্রস্তাব করছে৷ তৃতীয় পক্ষের কুকিজ ছাড়াই ব্রাউজ করা বেছে নেওয়া ব্যবহারকারীদের জন্য আপনাকে আপনার সাইট প্রস্তুত করতে হবে।
এই পৃষ্ঠায় আপনি সাইন-ইন পরিস্থিতিতে সবচেয়ে বেশি প্রভাবিত হতে পারে এমন তথ্যের পাশাপাশি সম্ভাব্য সমাধানগুলির উল্লেখ পাবেন৷
যদি আপনার ওয়েবসাইট শুধুমাত্র একই ডোমেন এবং সাবডোমেনের মধ্যে প্রবাহ পরিচালনা করে, যেমন publisher.example এবং login.publisher.example , তাহলে এটি ক্রস-সাইট কুকিজ ব্যবহার করবে না এবং আপনার সাইন-ইন প্রবাহ তৃতীয় পক্ষের দ্বারা প্রভাবিত হবে বলে আশা করা যায় না কুকি পরিবর্তন।
যাইহোক, যদি আপনার সাইট লগইন করার জন্য একটি পৃথক ডোমেন ব্যবহার করে, যেমন Google সাইন-ইন বা Facebook লগইন এর সাথে, অথবা আপনার সাইটটিকে একাধিক ডোমেন বা সাবডোমেন জুড়ে ব্যবহারকারীর প্রমাণীকরণ ভাগ করতে হয়, তাহলে আপনাকে আপনার সাইটে পরিবর্তন করতে হবে। ক্রস-সাইট কুকিজ থেকে দূরে একটি মসৃণ রূপান্তর নিশ্চিত করুন।
আপনার পরিচয়-সম্পর্কিত ব্যবহারকারীর যাত্রা পরীক্ষা করুন
আপনার সাইন-ইন প্রবাহ তৃতীয় পক্ষের কুকি পরিবর্তনের দ্বারা প্রভাবিত হয়েছে কিনা তা পরীক্ষা করার সর্বোত্তম উপায় হল আপনার নিবন্ধন, পাসওয়ার্ড পুনরুদ্ধার, সাইন-ইন এবং সাইন-আউট প্রবাহের মাধ্যমে তৃতীয় পক্ষের কুকি পরীক্ষার পতাকা সক্ষম করা ।
আপনি তৃতীয় পক্ষের কুকি সীমাবদ্ধ করার পরে এটি পরীক্ষা করার জন্য জিনিসগুলির একটি চেকলিস্ট:
- ব্যবহারকারী নিবন্ধন: একটি নতুন অ্যাকাউন্ট তৈরি করা প্রত্যাশা অনুযায়ী কাজ করে। যদি তৃতীয় পক্ষের পরিচয় প্রদানকারী ব্যবহার করে থাকেন, তাহলে পরীক্ষা করুন যে নতুন অ্যাকাউন্টের নিবন্ধন প্রতিটি ইন্টিগ্রেশনের জন্য কাজ করে।
- পাসওয়ার্ড পুনরুদ্ধার: পাসওয়ার্ড পুনরুদ্ধার আশানুরূপ কাজ করে, ওয়েব UI থেকে, ক্যাপচা , পাসওয়ার্ড পুনরুদ্ধারের ইমেল গ্রহণ করা পর্যন্ত।
- সাইন-ইন: সাইন-ইন ওয়ার্কফ্লো একই ডোমেনের মধ্যে কাজ করে এবং অন্য ডোমেনে নেভিগেট করার সময়। প্রতিটি সাইন-ইন ইন্টিগ্রেশন পরীক্ষা করতে মনে রাখবেন।
- সাইন-আউট: সাইন-আউট প্রক্রিয়া প্রত্যাশিতভাবে কাজ করে এবং ব্যবহারকারী সাইন-আউট প্রবাহের পরে সাইন-আউট থেকে যায়।
এছাড়াও আপনার পরীক্ষা করা উচিত যে অন্যান্য সাইটের বৈশিষ্ট্যগুলির জন্য ব্যবহারকারীর সাইন-ইন প্রয়োজন সেগুলি ক্রস-সাইট কুকি ছাড়াই কার্যকর থাকে, বিশেষ করে যদি সেগুলি ক্রস-সাইট সংস্থানগুলি লোড করা জড়িত থাকে৷ উদাহরণস্বরূপ, আপনি যদি ব্যবহারকারীর প্রোফাইল ছবি লোড করার জন্য একটি CDN ব্যবহার করেন, তবে নিশ্চিত করুন যে এটি এখনও কাজ করে। আপনার যদি ক্রিটিক্যাল ইউজার যাত্রা থাকে, যেমন চেকআউট, সাইন-ইন করার সময়, নিশ্চিত করুন যে এগুলো কাজ চালিয়ে যাচ্ছে।
পরবর্তী বিভাগগুলিতে, আপনি সেই প্রবাহগুলি কীভাবে প্রভাবিত হতে পারে সে সম্পর্কে আরও নির্দিষ্ট তথ্য পাবেন।
ফেডারেটেড পরিচয়
সাইন-ইন বোতাম যেমন Google এর সাথে সাইন ইন করুন , Facebook লগইন করুন এবং টুইটার দিয়ে লগ ইন করুন আপনার ওয়েবসাইট একটি ফেডারেটেড পরিচয় প্রদানকারী ব্যবহার করছে এমন একটি নির্দিষ্ট চিহ্ন। যেহেতু প্রতিটি ফেডারেটেড পরিচয় প্রদানকারীর নিজস্ব বাস্তবায়ন থাকবে, তাই সর্বোত্তম সমাধান হল আপনার প্রদানকারীর ডকুমেন্টেশন পরীক্ষা করা বা আরও নির্দেশনার জন্য তাদের সাথে যোগাযোগ করা।
আপনি যদি অপ্রচলিত Google সাইন-ইন জাভাস্ক্রিপ্ট প্ল্যাটফর্ম লাইব্রেরি ব্যবহার করেন, তাহলে প্রমাণীকরণ এবং অনুমোদনের জন্য আপনি কীভাবে নতুন Google আইডেন্টিটি পরিষেবা লাইব্রেরিতে স্থানান্তর করবেন সে সম্পর্কে তথ্য পেতে পারেন৷
নতুন Google আইডেন্টিটি সার্ভিসেস লাইব্রেরি ব্যবহার করে বেশিরভাগ সাইট তৃতীয় পক্ষের কুকি অবচয় করার জন্য প্রস্তুত, কারণ লাইব্রেরিটি সামঞ্জস্যের জন্য FedCM ব্যবহার করার জন্য নীরবে স্থানান্তর করবে। আমরা আপনার সাইটকে তৃতীয় পক্ষের কুকি টেস্টিং পতাকা সক্ষম করে পরীক্ষা করার পরামর্শ দিই এবং প্রয়োজনে FedCM মাইগ্রেশন চেকলিস্ট প্রস্তুত করতে ব্যবহার করুন।
আলাদা সাইন-ইন ডোমেন
কিছু ওয়েবসাইট একটি ভিন্ন ডোমেন ব্যবহার করে শুধুমাত্র এমন ব্যবহারকারীদের প্রমাণীকরণের জন্য যা একই-সাইট কুকির জন্য যোগ্যতা অর্জন করে না, যেমন একটি ওয়েবসাইট ব্যবহার করে example.com প্রধান সাইটের জন্য এবং login.example লগইন প্রবাহের জন্য, যার জন্য তৃতীয় পক্ষের কুকিজ অ্যাক্সেস করার প্রয়োজন হতে পারে নিশ্চিত করুন যে ব্যবহারকারী উভয় ডোমেন জুড়ে প্রমাণীকৃত।
এই দৃশ্যের জন্য সম্ভাব্য মাইগ্রেশন পাথ হল:
- ফার্স্ট-পার্টি ("একই-সাইট") কুকিজ ব্যবহার করার জন্য আপডেট করুন : ওয়েবসাইটের পরিকাঠামো পরিবর্তন করা যাতে লগইন ফ্লো মূল সাইটের মতো একই ডোমেনে (বা একটি সাবডোমেন) হোস্ট করা হয়, যা শুধুমাত্র প্রথম পক্ষের কুকিজ ব্যবহার করবে৷ পরিকাঠামো কিভাবে সেট আপ করা হয় তার উপর নির্ভর করে এর জন্য উচ্চতর প্রচেষ্টার প্রয়োজন হতে পারে।
- সম্পর্কিত ওয়েবসাইট সেট (RWS) ব্যবহার করুন: সম্পর্কিত ওয়েবসাইট সেটগুলি সম্পর্কিত ডোমেনের একটি ছোট গ্রুপের মধ্যে সীমিত ক্রস-সাইট কুকি অ্যাক্সেস সক্ষম করে। RWS হল একটি গোপনীয়তা স্যান্ডবক্স API যা এই ব্যবহারের ক্ষেত্রে সমর্থন করার জন্য নির্মিত। যাইহোক, RWS শুধুমাত্র সীমিত সংখ্যক ডোমেন জুড়ে ক্রস-সাইট কুকি অ্যাক্সেস সমর্থন করে।
- আপনি যদি 5টিরও বেশি সংশ্লিষ্ট ডোমেন জুড়ে ব্যবহারকারীদের প্রমাণীকরণ করেন, FedCM অন্বেষণ করুন : ফেডারেটেড ক্রেডেনশিয়াল ম্যানেজমেন্ট (FedCM) পরিচয় প্রদানকারীকে তৃতীয় পক্ষের কুকির প্রয়োজন ছাড়াই পরিচয়-সম্পর্কিত প্রবাহ পরিচালনা করতে Chrome-এর উপর নির্ভর করতে সক্ষম করে৷ আপনার ক্ষেত্রে, আপনার "সাইন-ইন ডোমেন" FedCM পরিচয় প্রদানকারী হিসাবে কাজ করতে পারে এবং আপনার অন্যান্য ডোমেন জুড়ে ব্যবহারকারীদের প্রমাণীকরণ করতে ব্যবহার করা যেতে পারে।
একাধিক ডোমেইন
যখন একটি ব্যবসার একাধিক পণ্য বিভিন্ন ডোমেন বা সাবডোমেনে হোস্ট করা থাকে, তখন এটি সেই সমস্ত পণ্য জুড়ে ব্যবহারকারীর সেশন ভাগ করতে চাইতে পারে, এমন একটি দৃশ্যের জন্য একাধিক ডোমেনের মধ্যে তৃতীয় পক্ষের কুকি অ্যাক্সেসের প্রয়োজন হতে পারে।
এই পরিস্থিতিতে, একই ডোমেনের অধীনে সমস্ত পণ্য হোস্ট করা প্রায়শই অবাস্তব। এই ক্ষেত্রে সম্ভাব্য সমাধান হল:
- সম্পর্কিত ওয়েবসাইট সেটগুলি ব্যবহার করুন: যখন সম্পর্কিত ডোমেনের একটি ছোট গ্রুপের মধ্যে ক্রস-সাইট কুকি অ্যাক্সেসের প্রয়োজন হয়।
- ফেডারেশন ক্রেডেনশিয়াল ম্যানেজমেন্ট (FedCM) ব্যবহার করুন : যখন ডোমেনের সংখ্যা বেশি হয়, আপনি একটি আলাদা সাইন-ইন ডোমেন ব্যবহার করে পরিচয় প্রদানকারী হিসেবে কাজ করতে পারেন এবং FedCM ব্যবহার করে আপনার সাইট জুড়ে ব্যবহারকারীদের প্রমাণীকরণ করতে পারেন।
সাইন-ইন সমাধান
তৃতীয় পক্ষের একক সাইন অন (SSO)
একটি SSO সমাধান বাস্তবায়নের জটিলতার কারণে, অনেক কোম্পানি একাধিক উত্সের মধ্যে সাইন-ইন অবস্থা ভাগ করে নেওয়ার জন্য একটি তৃতীয় পক্ষের সমাধান প্রদানকারী ব্যবহার করা বেছে নেয়। প্রদানকারীর উদাহরণগুলির মধ্যে রয়েছে Okta, Ping Identity, Google Cloud IAM বা Microsoft Entra ID।
তৃতীয় পক্ষের প্রদানকারী ব্যবহার করার সময়, সর্বোত্তম পদ্ধতি হল তৃতীয় পক্ষের কুকি পরিবর্তনগুলি কীভাবে সমাধানকে প্রভাবিত করবে এবং তারা তাদের পরিষেবার জন্য কোন পদ্ধতির সুপারিশ করবে সে সম্পর্কে প্রদানকারীর কাছ থেকে নির্দেশনা চাওয়া।
ওপেন সোর্স SSO সমাধান
অনেক কোম্পানি তাদের নিজস্ব SSO সমাধান বজায় রাখে তারা প্রতিষ্ঠিত শিল্প মান, যেমন OpenID Connect, OAuth বা SAML, অথবা Keycloak, WSO2, Auth.js বা Hydra এর মতো প্রতিষ্ঠিত ওপেন সোর্স প্রকল্পগুলি ব্যবহার করে তা করবে৷
কুকি পরিবর্তনগুলি কীভাবে তাদের সমাধানকে প্রভাবিত করতে পারে এবং সেই নির্দিষ্ট সমাধানের জন্য সর্বোত্তম স্থানান্তর পথ বুঝতে আমরা আপনার প্রদানকারীর জন্য ডকুমেন্টেশন পরীক্ষা করার পরামর্শ দিই৷
কাস্টম ইন-হাউস সমাধান
যদি আপনার সাইন-ইন সমাধানটি আগে ব্যবহারের ক্ষেত্রে একটির মধ্যে পড়ে এবং এটি ইন-হাউস তৈরি করা হয়, তাহলে তৃতীয় পক্ষের কুকিগুলিকে পর্যায়ক্রমে আউট করার জন্য প্রস্তুত করুন কীভাবে আপনার কোড অডিট করবেন এবং তৃতীয় পক্ষের কুকি পরিবর্তনের জন্য প্রস্তুত করবেন তা আরও বিশদে ব্যাখ্যা করে৷
এখন ব্যবস্থা নিন!
যদি আপনার ওয়েবসাইটটি ব্যবহারের ক্ষেত্রে একটির অধীনে পড়ে, তবে প্রমাণীকরণ প্রবাহকে প্রধান ডোমেনে স্থানান্তর করা থেকে শুরু করে সম্ভাব্য প্রভাব মোকাবেলার জন্য একাধিক সমাধান উপলব্ধ রয়েছে তাই এটি শুধুমাত্র প্রথম পক্ষের কুকি ব্যবহার করে, সম্পর্কিত ওয়েবসাইট সেটগুলি ব্যবহার করে একটি মধ্যে কুকি শেয়ার করার অনুমতি দেয় অল্প সংখ্যক ডোমেন, বা ফেডারেশন ক্রেডেনশিয়াল ম্যানেজমেন্টের সুবিধা।
আপনার পরিষেবা অডিট করার এবং তৃতীয় পক্ষের কুকি পরিবর্তনের জন্য প্রস্তুত করার মুহূর্ত এখন !