ফায়ারবেস প্রকল্পের ব্যবহারকারীরা

Firebase ব্যবহারকারী অবজেক্ট এমন একটি ব্যবহারকারী অ্যাকাউন্টের প্রতিনিধিত্ব করে যা আপনার প্রকল্পে একটি অ্যাপের জন্য সাইন আপ করেছে। অ্যাপগুলিতে সাধারণত অনেক নিবন্ধিত ব্যবহারকারী থাকে এবং একটি প্রকল্পের প্রতিটি অ্যাপ একটি ব্যবহারকারী ডাটাবেস ভাগ করে।

ব্যবহারকারীর দৃষ্টান্তগুলি Firebase Authentication দৃষ্টান্ত থেকে স্বতন্ত্র, তাই আপনি একই প্রসঙ্গে বিভিন্ন ব্যবহারকারীর একাধিক রেফারেন্স রাখতে পারেন এবং এখনও তাদের যেকোন পদ্ধতিতে কল করতে পারেন।

ব্যবহারকারীর বৈশিষ্ট্য

Firebase ব্যবহারকারীদের মৌলিক বৈশিষ্ট্যগুলির একটি নির্দিষ্ট সেট রয়েছে—একটি অনন্য আইডি, একটি প্রাথমিক ইমেল ঠিকানা, একটি নাম এবং একটি ফটো URL—প্রকল্পের ব্যবহারকারী ডাটাবেসে সংরক্ষিত, যা ব্যবহারকারী ( iOS , Android , web ) দ্বারা আপডেট করা যেতে পারে। আপনি সরাসরি ব্যবহারকারী বস্তুতে অন্যান্য বৈশিষ্ট্য যোগ করতে পারবেন না; পরিবর্তে, আপনি Google ক্লাউড ফায়ারস্টোরের মতো অন্য যেকোন স্টোরেজ পরিষেবাগুলিতে অতিরিক্ত বৈশিষ্ট্যগুলি সঞ্চয় করতে পারেন৷

প্রথমবার যখন কোনো ব্যবহারকারী আপনার অ্যাপে সাইন আপ করে, ব্যবহারকারীর প্রোফাইল ডেটা উপলভ্য তথ্য ব্যবহার করে পপুলেট করা হয়:

• ব্যবহারকারী যদি একটি ইমেল ঠিকানা এবং পাসওয়ার্ড দিয়ে সাইন আপ করে থাকেন, তবে শুধুমাত্র প্রাথমিক ইমেল ঠিকানার বৈশিষ্ট্যটি পপুলেট করা হয়৷
• ব্যবহারকারী যদি একটি ফেডারেটেড আইডেন্টিটি প্রদানকারীর সাথে সাইন আপ করে থাকে, যেমন Google বা Facebook, প্রদানকারীর দ্বারা উপলব্ধ করা অ্যাকাউন্ট তথ্য ব্যবহারকারীর প্রোফাইল তৈরি করতে ব্যবহার করা হয়
• যদি ব্যবহারকারী আপনার কাস্টম প্রমাণীকরণ সিস্টেমের সাথে সাইন আপ করে থাকেন, তাহলে আপনাকে অবশ্যই ব্যবহারকারীর প্রোফাইলে আপনি যে তথ্য চান তা স্পষ্টভাবে যোগ করতে হবে

একবার একটি ব্যবহারকারীর অ্যাকাউন্ট তৈরি হয়ে গেলে, আপনি ব্যবহারকারীর তথ্য পুনরায় লোড করতে পারেন যাতে ব্যবহারকারী অন্য ডিভাইসে যে কোনো পরিবর্তন করতে পারে।

সাইন-ইন প্রদানকারী

আপনি বিভিন্ন পদ্ধতি ব্যবহার করে আপনার অ্যাপে ব্যবহারকারীদের সাইন ইন করতে পারেন: ইমেল ঠিকানা এবং পাসওয়ার্ড, ফেডারেটেড পরিচয় প্রদানকারী এবং আপনার কাস্টম প্রমাণীকরণ সিস্টেম। আপনি একজন ব্যবহারকারীর সাথে একাধিক সাইন-ইন পদ্ধতি সংযুক্ত করতে পারেন: উদাহরণস্বরূপ, একজন ব্যবহারকারী একটি ইমেল ঠিকানা এবং একটি পাসওয়ার্ড ব্যবহার করে বা Google সাইন-ইন ব্যবহার করে একই অ্যাকাউন্টে সাইন ইন করতে পারেন৷

ব্যবহারকারীর উদাহরণ ব্যবহারকারীর সাথে লিঙ্ক করা প্রতিটি প্রদানকারীর ট্র্যাক রাখে। এটি আপনাকে প্রদানকারীর দেওয়া তথ্য ব্যবহার করে খালি প্রোফাইলের বৈশিষ্ট্য আপডেট করতে দেয়। ব্যবহারকারীদের পরিচালনা দেখুন ( iOS , Android , web )।

বর্তমান ব্যবহারকারী

যখন একজন ব্যবহারকারী সাইন আপ করেন বা সাইন ইন করেন, তখন সেই ব্যবহারকারী প্রমাণীকরণ উদাহরণের বর্তমান ব্যবহারকারী হয়ে যায়। উদাহরণটি ব্যবহারকারীর অবস্থা বজায় রাখে, যাতে পৃষ্ঠাটি রিফ্রেশ করা (একটি ব্রাউজারে) বা অ্যাপ্লিকেশনটি পুনরায় চালু করা ব্যবহারকারীর তথ্য হারায় না।

ব্যবহারকারী সাইন আউট করলে, Auth ইন্সট্যান্স ব্যবহারকারী অবজেক্টের একটি রেফারেন্স রাখা বন্ধ করে দেয় এবং তার অবস্থা আর টিকে থাকে না; কোন বর্তমান ব্যবহারকারী নেই. যাইহোক, ব্যবহারকারীর দৃষ্টান্তটি সম্পূর্ণরূপে কার্যকরী হতে থাকে: আপনি যদি এটির একটি রেফারেন্স রাখেন তবে আপনি এখনও ব্যবহারকারীর ডেটা অ্যাক্সেস এবং আপডেট করতে পারেন।

ব্যবহারকারীর জীবনচক্র

Auth উদাহরণের বর্তমান অবস্থা ট্র্যাক করার প্রস্তাবিত উপায় হল শ্রোতাদের (জাভাস্ক্রিপ্টে "পর্যবেক্ষক"ও বলা হয়) ব্যবহার করে। Auth অবজেক্টের সাথে প্রাসঙ্গিক কিছু ঘটলে একজন Auth শ্রোতাকে জানানো হবে। ব্যবহারকারীদের পরিচালনা দেখুন ( iOS , Android , web )।

নিম্নলিখিত পরিস্থিতিতে একজন প্রমাণী শ্রোতাকে অবহিত করা হয়:

• Auth অবজেক্টটি আরম্ভ করা শেষ করে এবং একজন ব্যবহারকারী ইতিমধ্যেই একটি পূর্ববর্তী সেশন থেকে সাইন ইন করেছেন, অথবা একটি পরিচয় প্রদানকারীর সাইন-ইন প্রবাহ থেকে পুনঃনির্দেশিত হয়েছে
• একজন ব্যবহারকারী সাইন ইন করে (বর্তমান ব্যবহারকারী সেট করা আছে)
• একজন ব্যবহারকারী সাইন আউট করে (বর্তমান ব্যবহারকারী শূন্য হয়ে যায়)
• বর্তমান ব্যবহারকারীর অ্যাক্সেস টোকেন রিফ্রেশ করা হয়েছে। এই ক্ষেত্রে নিম্নলিখিত পরিস্থিতিতে ঘটতে পারে:
  • অ্যাক্সেস টোকেনের মেয়াদ শেষ হয়ে যায়: এটি একটি সাধারণ পরিস্থিতি। রিফ্রেশ টোকেন টোকেনের একটি নতুন বৈধ সেট পেতে ব্যবহার করা হয়।
  • ব্যবহারকারী তাদের পাসওয়ার্ড পরিবর্তন করে: Firebase নতুন অ্যাক্সেস ইস্যু করে এবং টোকেন রিফ্রেশ করে এবং পুরানো টোকেনগুলির মেয়াদ শেষ হয়ে যায়। এটি স্বয়ংক্রিয়ভাবে ব্যবহারকারীর টোকেনের মেয়াদ শেষ করে এবং/অথবা প্রতিটি ডিভাইসে ব্যবহারকারীকে সাইন আউট করে, নিরাপত্তার কারণে।
  • ব্যবহারকারী পুনরায় প্রমাণীকরণ করে: কিছু কর্মের জন্য ব্যবহারকারীর শংসাপত্রগুলি সম্প্রতি জারি করা প্রয়োজন; এই ধরনের কর্মগুলির মধ্যে একটি অ্যাকাউন্ট মুছে ফেলা, একটি প্রাথমিক ইমেল ঠিকানা সেট করা এবং একটি পাসওয়ার্ড পরিবর্তন করা অন্তর্ভুক্ত। ব্যবহারকারীকে সাইন আউট করার এবং তারপরে ব্যবহারকারীকে আবার সাইন ইন করার পরিবর্তে, ব্যবহারকারীর কাছ থেকে নতুন শংসাপত্র পান এবং ব্যবহারকারী অবজেক্টের পুনরায় প্রমাণীকরণ পদ্ধতিতে নতুন শংসাপত্রগুলি পাস করুন৷

ব্যবহারকারীর স্ব-পরিষেবা

ডিফল্টরূপে, Firebase ব্যবহারকারীদের প্রশাসনিক হস্তক্ষেপ ছাড়াই তাদের অ্যাকাউন্টগুলি সাইন-আপ করতে এবং মুছে ফেলতে সক্ষম করে। অনেক পরিস্থিতিতে, এটি শেষ ব্যবহারকারীদের আপনার অ্যাপ্লিকেশন বা পরিষেবা এবং অনবোর্ড (বা অফবোর্ড) ন্যূনতম ঘর্ষণ সহ আবিষ্কার করতে সক্ষম করে।

তবে এমন পরিস্থিতি রয়েছে যেখানে আপনি ব্যবহারকারীদের ম্যানুয়ালি বা প্রোগ্রাম্যাটিকভাবে অ্যাডমিন SDK বা Firebase কনসোল ব্যবহার করে একজন প্রশাসকের দ্বারা তৈরি করতে চান৷ এই ক্ষেত্রে, আপনি Firebase Authentication সেটিংস পৃষ্ঠা থেকে ব্যবহারকারীর ক্রিয়াগুলি অক্ষম করতে পারেন, যা শেষ ব্যবহারকারীদের দ্বারা অ্যাকাউন্ট তৈরি এবং মুছে ফেলাকে বাধা দেয়। আপনি যদি মাল্টি-টেন্যান্সি ব্যবহার করেন, তাহলে প্রতি-ভাড়াটে ভিত্তিতে এই বৈশিষ্ট্যগুলিকে নিষ্ক্রিয় করার জন্য আপনাকে একটি HTTP অনুরোধ করতে হবে৷

যদি কোনও শেষ-ব্যবহারকারী আপনার সিস্টেমের মধ্যে একটি অ্যাকাউন্ট তৈরি বা মুছে ফেলার চেষ্টা করে, Firebase পরিষেবা একটি ত্রুটি কোড ফিরিয়ে দেবে: ওয়েব API কলগুলির জন্য auth/admin-restricted-operation , অথবা Android এবং iOS-এর জন্য ERROR_ADMIN_RESTRICTED_OPERATION ৷ ব্যবহারকারীকে আপনার পরিষেবার জন্য উপযুক্ত পদক্ষেপ নিতে বলে আপনার সামনের প্রান্তে ত্রুটিটি সুন্দরভাবে পরিচালনা করা উচিত।

প্রমাণীকরণ টোকেন

আপনি যখন Firebase সাথে প্রমাণীকরণ করেন, তখন তিন ধরনের প্রমাণীকরণ টোকেন আপনার সম্মুখীন হতে পারে:

Firebase আইডি টোকেন	কোনো ব্যবহারকারী কোনো অ্যাপে সাইন ইন করলে Firebase দ্বারা তৈরি করা হয়। এই টোকেনগুলি স্বাক্ষরিত JWT যেগুলি নিরাপদে একটি Firebase প্রকল্পে একজন ব্যবহারকারীকে সনাক্ত করে৷ এই টোকেনগুলিতে ব্যবহারকারীর আইডি স্ট্রিং সহ ব্যবহারকারীর মৌলিক প্রোফাইল তথ্য থাকে, যা Firebase প্রকল্পের জন্য অনন্য। যেহেতু আইডি টোকেনগুলির অখণ্ডতা যাচাই করা যেতে পারে , আপনি বর্তমানে সাইন ইন করা ব্যবহারকারীকে সনাক্ত করতে একটি ব্যাকএন্ড সার্ভারে পাঠাতে পারেন৷
পরিচয় প্রদানকারীর টোকেন	Google এবং Facebook এর মতো ফেডারেটেড পরিচয় প্রদানকারী দ্বারা তৈরি করা হয়েছে৷ এই টোকেনগুলির বিভিন্ন ফর্ম্যাট থাকতে পারে তবে প্রায়শই OAuth 2.0 অ্যাক্সেস টোকেন হয়৷ অ্যাপগুলি এই টোকেনগুলি ব্যবহার করে যাচাই করতে ব্যবহারকারীরা সফলভাবে পরিচয় প্রদানকারীর সাথে প্রমাণীকরণ করেছে এবং তারপরে সেগুলিকে Firebase পরিষেবাগুলির দ্বারা ব্যবহারযোগ্য শংসাপত্রে রূপান্তরিত করে৷
Firebase কাস্টম টোকেন	ব্যবহারকারীদের আপনার প্রমাণীকরণ সিস্টেম ব্যবহার করে একটি অ্যাপে সাইন ইন করার অনুমতি দেওয়ার জন্য আপনার কাস্টম প্রমাণীকরণ সিস্টেম দ্বারা তৈরি করা হয়েছে৷ কাস্টম টোকেন হল একটি পরিষেবা অ্যাকাউন্টের ব্যক্তিগত কী ব্যবহার করে স্বাক্ষরিত JWT। অ্যাপগুলি এই টোকেনগুলি ব্যবহার করে যেমন তারা ফেডারেটেড পরিচয় প্রদানকারীদের থেকে ফেরত টোকেনগুলি ব্যবহার করে৷

যাচাই করা ইমেল ঠিকানা

Firebase একটি ইমেল যাচাই করা বিবেচনা করে যদি এটি দুটি শর্ত পূরণ করে:

1. ব্যবহারকারী Firebase যাচাইকরণ প্রবাহ সম্পূর্ণ করে
2. ইমেলটি একটি বিশ্বস্ত পরিচয় প্রদানকারী দ্বারা যাচাই করা হয়, বা সংক্ষেপে আইডিপি৷

যে আইডিপিগুলি একবার ইমেল যাচাই করে, কিন্তু তারপরে ব্যবহারকারীদের পুনরায় যাচাইকরণের প্রয়োজন ছাড়াই ইমেল ঠিকানা পরিবর্তন করার অনুমতি দেয়, তারা বিশ্বস্ত নয়। যে আইডিপিগুলি হয় ডোমেনের মালিক বা সর্বদা যাচাইকরণের প্রয়োজন হয় সেগুলি বিশ্বস্ত বলে বিবেচিত হয়৷

বিশ্বস্ত প্রদানকারী:

• গুগল (@gmail.com ঠিকানার জন্য)
• ইয়াহু (@yahoo.com ঠিকানার জন্য)
• মাইক্রোসফট (@outlook.com এবং @hotmail.com ঠিকানার জন্য)
• Apple (সর্বদা যাচাই করা হয়, কারণ অ্যাকাউন্টগুলি সর্বদা যাচাই করা হয় এবং বহু-ফ্যাক্টর-প্রমাণিত)

অবিশ্বস্ত প্রদানকারী:

• ফেসবুক
• টুইটার
• গিটহাব
• Google, Yahoo, এবং Microsoft ডোমেনের জন্য যে পরিচয় প্রদানকারী দ্বারা জারি করা হয় না
• ইমেইল ভেরিফিকেশন ছাড়াই ইমেইল/পাসওয়ার্ড

কিছু পরিস্থিতিতে, যখন একজন ব্যবহারকারী একই ইমেল ঠিকানা ব্যবহার করে বিভিন্ন প্রদানকারীর সাথে সাইন ইন করে তখন Firebase অ্যাকাউন্টগুলিকে স্বয়ংক্রিয়ভাবে লিঙ্ক করবে। এটি শুধুমাত্র তখনই ঘটতে পারে যখন নির্দিষ্ট মানদণ্ড পূরণ করা হয়। কেন বোঝার জন্য, নিম্নলিখিত পরিস্থিতি বিবেচনা করুন: একজন ব্যবহারকারী একটি @gmail.com অ্যাকাউন্ট দিয়ে Google ব্যবহার করে সাইন ইন করে এবং একজন দূষিত অভিনেতা একই @gmail.com ঠিকানা ব্যবহার করে একটি অ্যাকাউন্ট তৈরি করে, কিন্তু Facebook এর মাধ্যমে সাইন ইন করে৷ এই দুটি অ্যাকাউন্ট স্বয়ংক্রিয়ভাবে লিঙ্ক করা হলে, দূষিত অভিনেতা ব্যবহারকারীর অ্যাকাউন্টে অ্যাক্সেস লাভ করবে।

নিম্নলিখিত কেসগুলি বর্ণনা করে যখন আমরা স্বয়ংক্রিয়ভাবে অ্যাকাউন্টগুলি লিঙ্ক করি এবং যখন আমরা ব্যবহারকারী বা বিকাশকারীর পদক্ষেপের প্রয়োজন হয় এমন একটি ত্রুটি নিক্ষেপ করি:

• ব্যবহারকারী একটি অবিশ্বস্ত প্রদানকারীর সাথে সাইন ইন করে, তারপর একই ইমেল দিয়ে অন্য অবিশ্বস্ত প্রদানকারীর সাথে সাইন ইন করে (উদাহরণস্বরূপ, Facebook এর পরে GitHub)। এটি একটি ত্রুটি নিক্ষেপ করে যার জন্য অ্যাকাউন্ট লিঙ্ক করা প্রয়োজন৷
• ব্যবহারকারী একটি বিশ্বস্ত প্রদানকারীর সাথে সাইন ইন করে, তারপর একই ইমেল দিয়ে অবিশ্বস্ত প্রদানকারীর সাথে সাইন ইন করে (উদাহরণস্বরূপ, Google অনুসরণ করে Facebook)। এটি একটি ত্রুটি নিক্ষেপ করে যার জন্য অ্যাকাউন্ট লিঙ্ক করা প্রয়োজন৷
• ব্যবহারকারী একটি অবিশ্বস্ত প্রদানকারীর সাথে সাইন ইন করে, তারপর একই ইমেল দিয়ে একটি বিশ্বস্ত প্রদানকারীর সাথে সাইন ইন করে (উদাহরণস্বরূপ, Facebook এর পরে Google)। বিশ্বস্ত প্রদানকারী অবিশ্বস্ত প্রদানকারীকে ওভাররাইট করে। ব্যবহারকারী যদি Facebook-এর সাথে আবার সাইন ইন করার চেষ্টা করে, তাহলে অ্যাকাউন্ট লিঙ্ক করার প্রয়োজনে একটি ত্রুটি ঘটবে।
• ব্যবহারকারী একটি বিশ্বস্ত প্রদানকারীর সাথে সাইন ইন করে, তারপরে একই ইমেল দিয়ে একটি ভিন্ন বিশ্বস্ত প্রদানকারীর সাথে সাইন ইন করে (উদাহরণস্বরূপ, Apple এর পরে Google)। উভয় প্রদানকারী ত্রুটি ছাড়াই লিঙ্ক করা হবে.

আপনি প্রশাসক SDK ব্যবহার করে যাচাইকৃত হিসাবে ম্যানুয়ালি একটি ইমেল সেট করতে পারেন, তবে আমরা কেবল তখনই এটি করার পরামর্শ দিই যদি আপনি জানেন যে ব্যবহারকারী সত্যিই ইমেলের মালিক৷