Firebase Authentication ব্যবহারকারী অবজেক্টটি এমন একটি ব্যবহারকারীর অ্যাকাউন্টকে বোঝায় যিনি আপনার প্রোজেক্টের কোনও অ্যাপে সাইন-আপ করেছেন। অ্যাপে সাধারণত অনেক রেজিস্টার করা ব্যবহারকারী থাকেন এবং কোনও প্রোজেক্টের প্রতিটি অ্যাপ একটি ব্যবহারকারীর ডেটাবেস শেয়ার করে।
ব্যবহারকারীর ইনস্ট্যান্স Firebase Authentication ইনস্ট্যান্স থেকে আলাদা, তাই আপনি একই কনটেক্সটে বিভিন্ন ব্যবহারকারীর একাধিক রেফারেন্স রাখতে এবং এখনও তাদের যেকোনও মেথড কল করতে পারবেন।
ব্যবহারকারীর প্রপার্টি
Authentication ব্যবহারকারীদের কাছে মৌলিক প্রপার্টির একটি নির্দিষ্ট সেট আছে—একটি অনন্য আইডি, একটি প্রাথমিক ইমেল আইডি, একটি নাম এবং একটি ফটো URL—যা প্রজেক্টের ব্যবহারকারীর ডেটাবেসে স্টোর করা আছে, যা ব্যবহারকারী আপডেট করতে পারেন (iOS, Android, ওয়েব)। আপনি সরাসরি ব্যবহারকারীর অবজেক্টে অন্য প্রপার্টি যোগ করতে পারবেন না; পরিবর্তে, আপনি Google Cloud Firestore-এর মতো অন্য কোনও স্টোরেজ পরিষেবায় অতিরিক্ত প্রপার্টি স্টোর করতে পারবেন।
কোনও ব্যবহারকারী প্রথমবার আপনার অ্যাপে সাইন-আপ করলে, উপলভ্য তথ্য ব্যবহার করে ব্যবহারকারীর প্রোফাইল ডেটা পপুলেট করা হয়:
- ব্যবহারকারী ইমেল আইডি ও পাসওয়ার্ড দিয়ে সাইন-আপ করলে, শুধুমাত্র প্রাথমিক ইমেল আইডি প্রপার্টি পূরণ করা হয়
- ব্যবহারকারী যদি Google বা Facebook-এর মতো কোনও ফেডারেটেড পরিচয় প্রদানকারীর মাধ্যমে সাইন-আপ করে থাকেন, তাহলে প্রদানকারীর দেওয়া অ্যাকাউন্টের তথ্য ব্যবহার করে ব্যবহারকারীর প্রোফাইল পূরণ করা হয়
- ব্যবহারকারী আপনার কাস্টম অথ সিস্টেমের মাধ্যমে সাইন-আপ করে থাকলে, ব্যবহারকারীর প্রোফাইলে আপনি যে তথ্য যোগ করতে চান, তা আপনাকে স্পষ্টভাবে যোগ করতে হবে
ব্যবহারকারীর অ্যাকাউন্ট তৈরি হয়ে গেলে, ব্যবহারকারী অন্য কোনও ডিভাইসে কোনও পরিবর্তন করে থাকলে তা অন্তর্ভুক্ত করতে ব্যবহারকারীর তথ্য আবার লোড করতে পারবেন।
সাইন-ইন পরিষেবা প্রদানকারী
আপনি বিভিন্ন পদ্ধতি ব্যবহার করে আপনার অ্যাপে ব্যবহারকারীদের সাইন-ইন করতে দিতে পারেন: ইমেল আইডি ও পাসওয়ার্ড, ফেডারেটেড আইডেন্টিটি প্রোভাইডার এবং আপনার কাস্টম অথ সিস্টেম। আপনি কোনও ব্যবহারকারীর সাথে একাধিক সাইন-ইন পদ্ধতি যুক্ত করতে পারেন: যেমন, কোনও ব্যবহারকারী ইমেল আইডি ও পাসওয়ার্ড ব্যবহার করে একই অ্যাকাউন্টে সাইন-ইন করতে পারেন অথবা Google-এর মাধ্যমে সাইন-ইন ব্যবহার করে।
ব্যবহারকারীর ইনস্ট্যান্স ব্যবহারকারীর সাথে লিঙ্ক করা প্রতিটি পরিষেবা প্রদানকারীর ট্র্যাক রাখে। এর ফলে, কোনও পরিষেবা প্রদানকারীর দেওয়া তথ্য ব্যবহার করে আপনি খালি প্রোফাইলের প্রপার্টি আপডেট করতে পারবেন। ব্যবহারকারী ম্যানেজ করা দেখুন (iOS, Android, ওয়েব)।
বর্তমান ব্যবহারকারী
কোনও ব্যবহারকারী সাইন-আপ বা সাইন-ইন করলে, সেই ব্যবহারকারী Auth ইনস্ট্যান্সের বর্তমান ব্যবহারকারী হয়ে যান। ইনস্ট্যান্স ব্যবহারকারীর স্টেট সেভ করে রাখে, যাতে পৃষ্ঠা (ব্রাউজারে) রিফ্রেশ করলে বা অ্যাপ্লিকেশন রিস্টার্ট করলে ব্যবহারকারীর তথ্য হারিয়ে না যায়।
ব্যবহারকারী সাইন-আউট করলে, Auth ইনস্ট্যান্স ব্যবহারকারী অবজেক্টের রেফারেন্স রাখা বন্ধ করে দেয় এবং আর সেটির স্টেট সেভ করে রাখে না; কোনও বর্তমান ব্যবহারকারী থাকে না। তবে, ব্যবহারকারীর ইনস্ট্যান্স সম্পূর্ণ কার্যকরী থাকে: আপনি যদি এটির রেফারেন্স রাখেন, তাহলে এখনও ব্যবহারকারীর ডেটা অ্যাক্সেস ও আপডেট করতে পারবেন।
ব্যবহারকারীর লাইফসাইকেল
Auth ইনস্ট্যান্সের বর্তমান অবস্থা ট্র্যাক করার জন্য সাজেস্ট করা পদ্ধতি হল লিসনার (JavaScript-এ "অবজার্ভার" নামেও পরিচিত) ব্যবহার করা। Auth লিসনারকে Auth অবজেক্টের সাথে প্রাসঙ্গিক কিছু ঘটলে যেকোনও সময় বিজ্ঞপ্তি পাঠানো হয়। ব্যবহারকারী ম্যানেজ করা (iOS, Android, ওয়েব) দেখুন।
নিম্নলিখিত পরিস্থিতিতে কোনও Auth লিসনারকে বিজ্ঞপ্তি পাঠানো হয়:
- Auth অবজেক্টের ইনিশিয়ালাইজ করা শেষ হয়ে গেছে এবং কোনও ব্যবহারকারী আগের সেশন থেকে আগেই সাইন-ইন করে থাকলে অথবা কোনও আইডেন্টিটি প্রোভাইডারের সাইন-ইন ফ্লো থেকে রিডাইরেক্ট করা হলে
- কোনও ব্যবহারকারী সাইন-ইন করলে (বর্তমান ব্যবহারকারী সেট করা হয়)
- কোনও ব্যবহারকারী সাইন-আউট করলে (বর্তমান ব্যবহারকারী নাল হয়ে যায়)
- বর্তমান ব্যবহারকারীর অ্যাক্সেস টোকেন রিফ্রেশ করা হয়। এইসব ক্ষেত্রে
নিম্নলিখিত শর্তে এটি হতে পারে:
- অ্যাক্সেস টোকেনের মেয়াদ শেষ হয়ে গেছে: এটি একটি সাধারণ পরিস্থিতি। রিফ্রেশ টোকেন ব্যবহার করে টোকেনের নতুন বৈধ সেট পাওয়া যায়।
- ব্যবহারকারী তার পাসওয়ার্ড পরিবর্তন করলে: Authentication নতুন অ্যাক্সেস ও রিফ্রেশ টোকেন ইস্যু করে এবং পুরনো টোকেন বাতিল করে দেয়। নিরাপত্তা সংক্রান্ত কারণে এটি ব্যবহারকারীর টোকেন অটোমেটিক এক্সপায়ার করে দেয় এবং/অথবা প্রতিটি ডিভাইস থেকে ব্যবহারকারীকে সাইন-আউট করে দেয়।
- ব্যবহারকারী আবার যাচাই করিয়ে নেন: কিছু অ্যাকশনের জন্য ব্যবহারকারীর ক্রেডেনশিয়াল সম্প্রতি ইস্যু করা হতে হবে; এই ধরনের অ্যাকশনের মধ্যে রয়েছে অ্যাকাউন্ট মুছে দেওয়া, প্রাইমারি ইমেল আইডি সেট করা এবং পাসওয়ার্ড পরিবর্তন করা। ব্যবহারকারীকে সাইন-আউট করে আবার সাইন-ইন করানোর পরিবর্তে, ব্যবহারকারীর থেকে নতুন ক্রেডেনশিয়াল নিন এবং ব্যবহারকারীর অবজেক্টের আবার যাচাইকরণ পদ্ধতিতে নতুন ক্রেডেনশিয়াল পাস করুন।
ব্যবহারকারীর সেল্ফ-সার্ভিস
সাধারণত, Firebase Authentication ব্যবহারকারীদের সাইন-আপ করতে এবং তাদের অ্যাকাউন্ট মুছে দিতে অ্যাডমিনিস্ট্রেটিভ হস্তক্ষেপ ছাড়াই অনুমতি দেয়। অনেক পরিস্থিতিতে, এটি শেষ ব্যবহারকারীদের আপনার অ্যাপ্লিকেশন বা পরিষেবা খুঁজে পেতে এবং ন্যূনতম বাধা সহ অনবোর্ড (বা অফবোর্ড) করতে সাহায্য করে।
তবে, এমন কিছু পরিস্থিতিও রয়েছে যেখানে আপনি চান যে কোনও অ্যাডমিনিস্ট্রেটর Admin SDK বা Firebase কনসোল ব্যবহার করে ব্যবহারকারীদের ম্যানুয়ালি বা প্রোগ্রামাটিক উপায়ে তৈরি করুন। এইসব ক্ষেত্রে, আপনি Firebase Authentication সেটিংস পৃষ্ঠা থেকে ব্যবহারকারীর অ্যাকশন বন্ধ করতে পারবেন, যা এন্ড-ইউজারদের অ্যাকাউন্ট তৈরি ও মুছে ফেলা থেকে আটকায়। আপনি মাল্টি-টেনেন্সি ব্যবহার করলে, আপনাকে টেন্যান্ট পিছু ভিত্তিতে এইসব ফিচার বন্ধ করতে একটি HTTP অনুরোধ করতে হবে।
কোনও এন্ড-ইউজার আপনার সিস্টেমে অ্যাকাউন্ট তৈরি বা মুছে দেওয়ার চেষ্টা করলে,
Firebase Authentication পরিষেবা একটি সমস্যার কোড রিটার্ন করবে:
auth/admin-restricted-operation ওয়েব API কলের জন্য অথবা ERROR_ADMIN_RESTRICTED_OPERATION Android ও iOS-এর জন্য। আপনার পরিষেবার জন্য উপযুক্ত
অ্যাকশন নিতে ব্যবহারকারীকে বলে আপনার ফ্রন্ট-এন্ডে সমস্যাটি
সাবলীলভাবে হ্যান্ডেল করা উচিত।
যাচাইকরণ টোকেন
Authentication-এর মাধ্যমে যাচাইকরণ করার সময়, আপনি তিন ধরনের যাচাইকরণ টোকেন দেখতে পেতে পারেন:
| Authentication আইডি টোকেন | Authentication তৈরি করা হয় যখন কোনও ব্যবহারকারী কোনও অ্যাপে সাইন-ইন করেন। এইসব টোকেন হল সাইন করা JWT যা কোনও Firebase প্রোজেক্টে কোনও ব্যবহারকারীকে নিরাপদে শনাক্ত করে। এইসব টোকেনে ব্যবহারকারীর ID স্ট্রিং সহ কোনও ব্যবহারকারীর প্রাথমিক প্রোফাইল তথ্য থাকে, যা Firebase প্রোজেক্টের জন্য অনন্য। কারণ আইডি টোকেনের ইন্টিগ্রিটি যাচাই করা যায়, তাই বর্তমানে সাইন-ইন করা ব্যবহারকারীকে শনাক্ত করতে আপনি সেগুলি ব্যাক-এন্ড সার্ভারে পাঠাতে পারেন। |
| পরিচয় প্রদানকারী টোকেন | ফেডারেটেড পরিচয় প্রদানকারী, যেমন Google ও Facebook-এর মাধ্যমে তৈরি করা হয়। এইসব টোকেনের ফর্ম্যাট আলাদা আলাদা হতে পারে, তবে সেগুলি প্রায়ই OAuth 2.0 অ্যাক্সেস টোকেন হয়। ব্যবহারকারী যে পরিচয় প্রদানকারীর মাধ্যমে সফলভাবে পরিচয় যাচাই করেছেন তা যাচাই করতে অ্যাপ এইসব টোকেন ব্যবহার করে এবং তারপরে সেগুলিকে Authentication পরিষেবার ব্যবহারযোগ্য ক্রেডেনশিয়ালে কনভার্ট করে। |
| Authentication কাস্টম টোকেন | আপনার কাস্টম অথ সিস্টেমের মাধ্যমে তৈরি করা হয় যাতে ব্যবহারকারীরা আপনার অথ সিস্টেম ব্যবহার করে কোনও অ্যাপে সাইন-ইন করতে পারেন। কাস্টম টোকেন হল JWT পরিষেবা অ্যাকাউন্টের ব্যক্তিগত কী ব্যবহার করে স্বাক্ষর করা হয়। ফেডারেটেড পরিচয় প্রদানকারীর থেকে পাওয়া টোকেন যেভাবে অ্যাপ ব্যবহার করে, ঠিক সেইভাবেই এইসব টোকেন ব্যবহার করে। |
যাচাই করা ইমেল আইডি
Authentication কোনও ইমেলকে যাচাই করা হয়েছে বলে তখনই বিবেচনা করে যখন সেটি দুটি শর্ত পূরণ করে:
- ব্যবহারকারী Authentication যাচাইকরণ ফ্লো সম্পূর্ণ করেন
- ইমেলটি একটি বিশ্বস্ত পরিচয় প্রদানকারী বা সংক্ষেপে IdP যাচাই করে।
যেসব IdP ইমেল একবার যাচাই করে, কিন্তু তারপর আবার যাচাই না করেই ব্যবহারকারীদের ইমেল আইডি পরিবর্তন করার অনুমতি দেয়, সেগুলি বিশ্বস্ত নয়। যেসব IdP ডোমেনের মালিক অথবা সবসময় যাচাইকরণ প্রয়োজন হয় সেগুলিকে বিশ্বস্ত হিসেবে বিবেচনা করা হয়।
বিশ্বস্ত পরিষেবা প্রদানকারী:
- Google (for @gmail.com addresses)
- Yahoo (for @yahoo.com addresses)
- Microsoft (for @outlook.com and @hotmail.com addresses)
- Apple (সবসময় যাচাই করা হয়, কারণ অ্যাকাউন্ট সবসময় যাচাই করা হয় এবং বহু-স্তরীয় যাচাইকরণ করা হয়)
অবিশ্বস্ত পরিষেবা প্রদানকারী:
- GitHub
- সেই পরিচয় প্রদানকারীর ইস্যু করা নয় এমন ডোমেনের জন্য Google, Yahoo ও Microsoft
- ইমেল যাচাইকরণ ছাড়া ইমেল / পাসওয়ার্ড
কিছু ক্ষেত্রে, Authentication ব্যবহারকারী একই ইমেল আইডি দিয়ে আলাদা আলাদা পরিষেবা প্রদানকারীর মাধ্যমে সাইন-ইন করলে, অ্যাকাউন্ট অটোমেটিক লিঙ্ক করবে। তবে, এটি তখনই সম্ভব যখন নির্দিষ্ট মানদণ্ড পূরণ করা হয়। কেন এমন হয় তা বুঝতে, নিম্নলিখিত পরিস্থিতি বিবেচনা করুন: একজন ব্যবহারকারী @gmail.com অ্যাকাউন্ট দিয়ে Google-এ সাইন-ইন করেন এবং একজন ক্ষতিকারক ব্যক্তি একই @gmail.com আইডি ব্যবহার করে অ্যাকাউন্ট তৈরি করেন, কিন্তু Facebook-এর মাধ্যমে সাইন-ইন করেন। এই দুটি অ্যাকাউন্ট অটোমেটিক লিঙ্ক করা হলে, ক্ষতিকারক ব্যক্তি ব্যবহারকারীর অ্যাকাউন্টে অ্যাক্সেস পেয়ে যাবে।
নিম্নলিখিত ক্ষেত্রে আমরা কখন অ্যাকাউন্ট অটোমেটিক লিঙ্ক করি এবং কখন ব্যবহারকারী বা ডেভেলপার অ্যাকশন প্রয়োজন হয় এমন ত্রুটি দেখাই তা বর্ণনা করা হয়েছে:
- ব্যবহারকারী কোনও বিশ্বাসযোগ্য নয় এমন পরিষেবা প্রদানকারীর মাধ্যমে সাইন-ইন করেন, তারপর একই ইমেল আইডি দিয়ে অন্য কোনও বিশ্বাসযোগ্য নয় এমন পরিষেবা প্রদানকারীর মাধ্যমে সাইন-ইন করেন (যেমন, Facebook-এর পরে GitHub)। এর ফলে অ্যাকাউন্ট লিঙ্ক করার প্রয়োজন হয় এবং একটি সমস্যা দেখা দেয়।
- ব্যবহারকারী প্রথমে বিশ্বস্ত প্রোভাইডারের মাধ্যমে সাইন-ইন করেন, তারপর একই ইমেল আইডি দিয়ে অবিশ্বস্ত প্রোভাইডারের মাধ্যমে সাইন-ইন করেন (যেমন, প্রথমে Google তারপর Facebook)। এর ফলে অ্যাকাউন্ট লিঙ্ক করার প্রয়োজন হয় এবং একটি সমস্যা দেখা দেয়।
- ব্যবহারকারী প্রথমে একটি অবিশ্বস্ত প্রদানকারীর মাধ্যমে সাইন-ইন করেন, তারপর একই ইমেল আইডি ব্যবহার করে একটি বিশ্বস্ত প্রদানকারীর মাধ্যমে সাইন-ইন করেন (যেমন, প্রথমে Facebook তারপর Google)। বিশ্বস্ত প্রদানকারী, অবিশ্বস্ত প্রদানকারীকে ওভাররাইট করে। ব্যবহারকারী Facebook দিয়ে আবার সাইন-ইন করার চেষ্টা করলে, অ্যাকাউন্ট লিঙ্ক করার প্রয়োজন হবে বলে একটি সমস্যা হবে।
- ব্যবহারকারী কোনও বিশ্বস্ত পরিষেবা প্রদানকারীর মাধ্যমে সাইন-ইন করেন, তারপর একই ইমেল আইডি দিয়ে অন্য কোনও বিশ্বস্ত পরিষেবা প্রদানকারীর মাধ্যমে সাইন-ইন করেন (যেমন, প্রথমে Apple তারপর Google)। দুটি পরিষেবা প্রদানকারীই কোনও সমস্যা ছাড়াই লিঙ্ক করা হবে।
আপনি Admin SDK ব্যবহার করে কোনও ইমেলকে ম্যানুয়ালি যাচাই করা হিসেবে সেট করতে পারবেন, তবে আমরা সাজেস্ট করি যে ব্যবহারকারী সত্যিই ইমেলের মালিক হলে তবেই এটি করুন।