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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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