নিরাপত্তা বিধি এবং ফায়ারবেস প্রমাণীকরণ

Firebase Security Rules একাধিক স্তরের জটিলতাকে সমর্থন করে এমন একটি বিন্যাসে অ্যাক্সেস নিয়ন্ত্রণ এবং ডেটা বৈধতা প্রদান করে। ব্যবহারকারী-ভিত্তিক এবং ভূমিকা-ভিত্তিক অ্যাক্সেস সিস্টেম তৈরি করতে যা আপনার ব্যবহারকারীদের ডেটা সুরক্ষিত রাখে, Firebase Security Rules সাথে Firebase Authentication ব্যবহার করুন।

ব্যবহারকারীদের সনাক্ত করুন

Authentication আপনার ডেটাতে অ্যাক্সেসের অনুরোধকারী ব্যবহারকারীদের সনাক্ত করে এবং সেই তথ্যটিকে একটি পরিবর্তনশীল হিসাবে প্রদান করে যা আপনি আপনার নিয়মে লিভারেজ করতে পারেন। auth ভেরিয়েবলে নিম্নলিখিত তথ্য রয়েছে:

  • uid : একটি অনন্য ব্যবহারকারী আইডি, অনুরোধকারী ব্যবহারকারীকে বরাদ্দ করা হয়েছে।
  • token : Authentication দ্বারা সংগৃহীত মানগুলির একটি মানচিত্র।

auth.token ভেরিয়েবলে নিম্নলিখিত মান রয়েছে:

মাঠ বর্ণনা
email অ্যাকাউন্টের সাথে যুক্ত ইমেল ঠিকানা, যদি উপস্থিত থাকে।
email_verified true যদি ব্যবহারকারী যাচাই করে থাকে যে তাদের email ঠিকানায় অ্যাক্সেস আছে। কিছু প্রদানকারী স্বয়ংক্রিয়ভাবে তাদের মালিকানাধীন ইমেল ঠিকানা যাচাই করে।
phone_number অ্যাকাউন্টের সাথে যুক্ত ফোন নম্বর, যদি উপস্থিত থাকে।
name ব্যবহারকারীর প্রদর্শনের নাম, যদি সেট করা থাকে।
sub ব্যবহারকারীর Firebase UID. এটি একটি প্রকল্পের মধ্যে অনন্য।
firebase.identities এই ব্যবহারকারীর অ্যাকাউন্টের সাথে যুক্ত সমস্ত পরিচয়ের অভিধান। অভিধানের কীগুলি নিম্নলিখিতগুলির মধ্যে যেকোনো একটি হতে পারে: email , phone , google.com , facebook.com , github.com , twitter.com । অভিধানের মান হল অ্যাকাউন্টের সাথে যুক্ত প্রতিটি পরিচয় প্রদানকারীর জন্য অনন্য শনাক্তকারীর অ্যারে। উদাহরণস্বরূপ, auth.token.firebase.identities["google.com"][0] এ অ্যাকাউন্টের সাথে যুক্ত প্রথম Google ব্যবহারকারী আইডি রয়েছে৷
firebase.sign_in_provider সাইন-ইন প্রদানকারী এই টোকেনটি পেতে ব্যবহৃত নিম্নলিখিত স্ট্রিংগুলির মধ্যে একটি হতে পারে: custom , password , phone , anonymous , google.com , facebook.com , github.com , twitter.com
firebase.tenant অ্যাকাউন্টের সাথে সংশ্লিষ্ট ভাড়াটে আইডি, যদি উপস্থিত থাকে। যেমন tenant2-m6tyz

আপনি যদি কাস্টমাইজড প্রমাণীকরণ বৈশিষ্ট্য যোগ করতে চান, তাহলে auth.token ভেরিয়েবলে আপনার নির্দিষ্ট করা কোনো কাস্টম দাবিও থাকে।

যখন অ্যাক্সেসের অনুরোধকারী ব্যবহারকারী সাইন ইন না করে, auth ভেরিয়েবলটি null হয়। আপনি আপনার নিয়মে এটির সুবিধা নিতে পারেন যদি, উদাহরণস্বরূপ, আপনি প্রমাণীকৃত ব্যবহারকারীদের পড়ার অ্যাক্সেস সীমিত করতে চান — auth != null । যাইহোক, আমরা সাধারণত লেখার অ্যাক্সেস সীমিত করার পরামর্শ দিই।

auth পরিবর্তনশীল সম্পর্কে আরও তথ্যের জন্য, Cloud Firestore , Realtime Database এবং Cloud Storage জন্য রেফারেন্স ডকুমেন্টেশন দেখুন।

নিয়ম অনুযায়ী ব্যবহারকারীর তথ্য ব্যবহার করুন

অনুশীলনে, আপনার নিয়মে প্রমাণীকৃত তথ্য ব্যবহার করে আপনার নিয়মগুলিকে আরও শক্তিশালী এবং নমনীয় করে তোলে। আপনি ব্যবহারকারীর পরিচয়ের উপর ভিত্তি করে ডেটা অ্যাক্সেস নিয়ন্ত্রণ করতে পারেন।

আপনার নিয়মে, auth ভেরিয়েবলের তথ্য কীভাবে সংজ্ঞায়িত করুন — অনুরোধকারীর ব্যবহারকারীর তথ্য — অনুরোধ করা ডেটার সাথে যুক্ত ব্যবহারকারীর তথ্যের সাথে মেলে।

উদাহরণস্বরূপ, আপনার অ্যাপ নিশ্চিত করতে চায় যে ব্যবহারকারীরা কেবল তাদের নিজস্ব ডেটা পড়তে এবং লিখতে পারে। এই পরিস্থিতিতে, আপনি অনুরোধ করা ডেটাতে auth.uid ভেরিয়েবল এবং ব্যবহারকারী আইডির মধ্যে একটি মিল চাইবেন:

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure the uid of the requesting user matches name of the user
    // document. The wildcard expression {userId} makes the userId variable
    // available in rules.
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Realtime Database

{
  "rules": {
    "users": {
      "$userId": {
        // grants write access to the owner of this user account
        // whose uid must exactly match the key ($userId)
        ".write": "$userId === auth.uid"
      }
    }
  }
}

Cloud Storage

service firebase.storage {
  // Only a user can upload their file, but anyone can view it
  match /users/{userId}/{fileName} {
    allow read;
    allow write: if request.auth != null && request.auth.uid == userId;
  }
}

কাস্টম ব্যবহারকারীর তথ্য সংজ্ঞায়িত করুন

আপনি আপনার অ্যাপের ব্যবহারকারীদের জন্য নির্ধারিত কাস্টম ক্ষেত্রগুলিকে সংজ্ঞায়িত করতে auth ভেরিয়েবলটিকে আরও লিভারেজ করতে পারেন৷

উদাহরণস্বরূপ, ধরে নিন আপনি একটি "প্রশাসক" ভূমিকা তৈরি করতে চান যা নির্দিষ্ট পাথে লেখার অ্যাক্সেস সক্ষম করে। আপনি ব্যবহারকারীদের কাছে সেই বৈশিষ্ট্যটি বরাদ্দ করবেন এবং তারপরে পাথগুলিতে অ্যাক্সেস দেওয়ার নিয়মগুলিতে এটিকে লিভারেজ করবেন।

Cloud Firestore , আপনি ব্যবহারকারীদের নথিতে একটি কাস্টম ক্ষেত্র যোগ করতে পারেন এবং আপনার নিয়মে এমবেডেড পড়ার মাধ্যমে সেই ক্ষেত্রের মান পুনরুদ্ধার করতে পারেন। সুতরাং, আপনার প্রশাসক-ভিত্তিক নিয়ম নিম্নলিখিত উদাহরণের মত দেখাবে:

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents/some_collection: {
    // Remember that, in Cloud Firestore, reads embedded in your rules are billed operations
    write: if request.auth != null && get(/databases/(database)/documents/users/$(request.auth.uid)).data.admin == true;
    read: if request.auth != null;
  }
}

আপনি Authentication কাস্টম দাবি তৈরি করার পরে Rules কাস্টম দাবিগুলি অ্যাক্সেস করতে পারেন৷ তারপর আপনি auth.token ভেরিয়েবল ব্যবহার করে সেই কাস্টম দাবিগুলি উল্লেখ করতে পারেন৷

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, check for an admin claim
    allow write: if request.auth.token.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if request.auth.token.reader == "true";
     allow write: if request.auth.token.writer == "true";
   }
  }
}

Realtime Database

{
  "rules": {
    "some_path/$sub_path": {
      // Create a custom claim for the admin role
      ".write": "auth.uid !== null && auth.token.writer === true"
      ".read": "auth.uid !== null"
      }
    }
  }

Cloud Storage

service firebase.storage {
  // Create a custom claim for the admin role
  match /files/{fileName} {
    allow read: if request.auth.uid != null;
    allow write: if request.auth.token.admin == true;
  }
}

Authentication সুবিধা প্রদানের মৌলিক Rules আরও উদাহরণ দেখতে, মৌলিক নিরাপত্তা নিয়মগুলি দেখুন।