মৌলিক নিরাপত্তা নিয়ম

Firebase Security Rules আপনাকে আপনার সংরক্ষিত ডেটাতে অ্যাক্সেস নিয়ন্ত্রণ করতে দেয়। এর নমনীয় রুলস সিনট্যাক্সের কারণে আপনি এমন নিয়ম তৈরি করতে পারেন যা যেকোনো কিছুর সাথে মিল রাখে, যেমন—পুরো ডেটাবেসে সমস্ত রাইট অপারেশন থেকে শুরু করে কোনো নির্দিষ্ট ডকুমেন্টের অপারেশন পর্যন্ত।

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

আপনার নিয়মগুলি অ্যাক্সেস এবং আপডেট করতে, Firebase Security Rules পরিচালনা এবং স্থাপন করুন" অংশে বর্ণিত পদক্ষেপগুলি অনুসরণ করুন।

ডিফল্ট নিয়মাবলী: লক করা মোড

আপনি যখন Firebase কনসোলে একটি ডেটাবেস বা স্টোরেজ ইনস্ট্যান্স তৈরি করেন, তখন আপনি বেছে নেন যে আপনার Firebase Security Rules আপনার ডেটাতে অ্যাক্সেস সীমাবদ্ধ করবে ( লকড মোড ) নাকি যে কাউকে অ্যাক্সেসের অনুমতি দেবে ( টেস্ট মোড )। Cloud Firestore এবং Realtime Database , লকড মোডের জন্য ডিফল্ট নিয়মগুলি সমস্ত ব্যবহারকারীকে অ্যাক্সেস করতে দেয় না। Cloud Storage , শুধুমাত্র প্রমাণীকৃত ব্যবহারকারীরাই স্টোরেজ বাকেটগুলি অ্যাক্সেস করতে পারে।

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

{
  "rules": {
    ".read": false,
    ".write": false
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

উন্নয়ন-পরিবেশ নিয়মাবলী

আপনার অ্যাপ নিয়ে কাজ করার সময়, আপনি হয়তো আপনার ডেটাতে তুলনামূলকভাবে উন্মুক্ত বা অবাধ অ্যাক্সেস চাইতে পারেন। তবে, আপনার অ্যাপটি প্রোডাকশনে ডেপ্লয় করার আগে অবশ্যই আপনার Security Rules আপডেট করে নেবেন। এও মনে রাখবেন যে, আপনি যদি আপনার অ্যাপটি ডেপ্লয় করেন, তবে তা সবার জন্য উন্মুক্ত হয়ে যায় — এমনকি আপনি সেটি চালু না করলেও।

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

সকল প্রমাণীকৃত ব্যবহারকারী

যদিও আমরা সাইন ইন করা যেকোনো ব্যবহারকারীর কাছে আপনার ডেটা অ্যাক্সেসযোগ্য রাখার পরামর্শ দিই না, তবে আপনার অ্যাপ তৈরি করার সময় যেকোনো অথেনটিকেটেড ব্যবহারকারীর জন্য অ্যাক্সেস সেট করা সহায়ক হতে পারে।

service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow read, write: if request.auth != null;
    }
  }
}

{
  "rules": {
    "some_path": {
      ".read": "auth.uid !== null",
      ".write": "auth.uid !== null"
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    match /some_folder/{fileName} {
      allow read, write: if request.auth != null;
    }
  }
}

উৎপাদন-প্রস্তুত নিয়মাবলী

আপনার অ্যাপটি ডেপ্লয় করার প্রস্তুতি নেওয়ার সময়, নিশ্চিত করুন যে আপনার ডেটা সুরক্ষিত আছে এবং ব্যবহারকারীদের যথাযথভাবে অ্যাক্সেস দেওয়া হয়েছে। ব্যবহারকারী-ভিত্তিক অ্যাক্সেস সেট আপ করতে Authentication ব্যবহার করুন এবং ডেটা-ভিত্তিক অ্যাক্সেস সেট আপ করতে সরাসরি আপনার ডাটাবেস থেকে ডেটা পড়ুন।

আপনার ডেটা সাজানোর সময় নিয়ম লেখার কথা বিবেচনা করুন, কারণ আপনি যেভাবে নিয়মগুলো তৈরি করেন, তা বিভিন্ন পাথে ডেটাতে অ্যাক্সেস সীমাবদ্ধ করার পদ্ধতিকে প্রভাবিত করে।

শুধুমাত্র বিষয়বস্তুর মালিকের প্রবেশাধিকার

এই নিয়মগুলি শুধুমাত্র বিষয়বস্তুর প্রমাণীকৃত মালিকের জন্য প্রবেশাধিকার সীমাবদ্ধ করে। ডেটাটি কেবল একজন ব্যবহারকারীই পড়তে ও লিখতে পারেন এবং ডেটা পাথে ব্যবহারকারীর আইডি থাকে।

এই নিয়মটি কখন কাজ করে: এই নিয়মটি ভালোভাবে কাজ করে যদি ডেটা ব্যবহারকারী অনুযায়ী বিচ্ছিন্ন থাকে — অর্থাৎ, যে ব্যবহারকারী ডেটাটি তৈরি করেছেন, শুধুমাত্র সেই ব্যবহারকারীরই ডেটাটি অ্যাক্সেস করার প্রয়োজন হয়।

যখন এই নিয়মটি কাজ করে না: একাধিক ব্যবহারকারী যখন একই ডেটা লিখতে বা পড়তে চান, তখন এই নিয়মাবলী কাজ করে না — ব্যবহারকারীরা ডেটা ওভাররাইট করে ফেলবেন অথবা তাদের তৈরি করা ডেটা অ্যাক্সেস করতে পারবেন না।

এই নিয়মটি সেট আপ করতে: এমন একটি নিয়ম তৈরি করুন যা নিশ্চিত করে যে, ডেটা পড়া বা লেখার অ্যাক্সেসের জন্য অনুরোধকারী ব্যবহারকারীই সেই ডেটার মালিক।

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{userId}/{document} {
      allow read, write: if request.auth != null && request.auth.uid == userId
    }
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Allow only authenticated content owners access to their data
        ".read": "auth !== null && auth.uid === $uid",
        ".write": "auth !== null && auth.uid === $uid"
      }
    }
  }
}

// Grants a user access to a node matching their user ID
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

সরকারি ও ব্যক্তিগত মিশ্র প্রবেশাধিকার

এই নিয়মটি যে কাউকে একটি ডেটাসেট পড়ার অনুমতি দেয়, কিন্তু একটি নির্দিষ্ট পাথে ডেটা তৈরি বা পরিবর্তন করার ক্ষমতা শুধুমাত্র প্রমাণীকৃত কন্টেন্ট মালিকের জন্য সীমাবদ্ধ করে।

এই নিয়মটি কখন কার্যকর: এই নিয়মটি সেইসব অ্যাপের জন্য ভালোভাবে কাজ করে, যেগুলিতে সর্বজনীনভাবে পাঠযোগ্য উপাদানের প্রয়োজন হয়, কিন্তু সেই উপাদানগুলির মালিকদের জন্য সম্পাদনার অ্যাক্সেস সীমাবদ্ধ রাখতে হয়। উদাহরণস্বরূপ, একটি চ্যাট অ্যাপ বা ব্লগ।

যখন এই নিয়মটি কাজ করে না: ‘শুধুমাত্র কন্টেন্ট-মালিক’ নিয়মটির মতোই, এই নিয়মসেটটিও তখন কাজ করে না যখন একাধিক ব্যবহারকারীকে একই ডেটা সম্পাদনা করতে হয়। ব্যবহারকারীরা শেষ পর্যন্ত একে অপরের ডেটা ওভাররাইট করে ফেলবে।

এই নিয়মটি সেট আপ করতে: এমন একটি নিয়ম তৈরি করুন যা সকল ব্যবহারকারীকে (অথবা সকল প্রমাণীকৃত ব্যবহারকারীকে) পড়ার অ্যাক্সেস দেয় এবং ডেটা লেখক ব্যবহারকারীই যে এর মালিক, তা নিশ্চিত করে।

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      // Allow public reads
      allow read: if true
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;
      // Allow deletion if the current user owns the existing document
      allow delete: if request.auth.uid == resource.data.author_uid;
    }
  }
}

{
// Allow anyone to read data, but only authenticated content owners can
// make changes to their data

  "rules": {
    "some_path": {
      "$uid": {
        ".read": true,
        // or ".read": "auth.uid !== null" for only authenticated users
        ".write": "auth.uid === $uid"
      }
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}

বৈশিষ্ট্য-ভিত্তিক এবং ভূমিকা-ভিত্তিক অ্যাক্সেস

এই নিয়মগুলো কার্যকর করার জন্য, আপনাকে অবশ্যই আপনার ডেটাতে ব্যবহারকারীদের অ্যাট্রিবিউট সংজ্ঞায়িত ও নির্ধারণ করতে হবে। Firebase Security Rules অ্যাক্সেস নিশ্চিত বা প্রত্যাখ্যান করার জন্য আপনার ডাটাবেস বা ফাইলের মেটাডেটার ডেটার সাথে অনুরোধটি মিলিয়ে দেখে।

এই নিয়মটি কখন কাজ করে: আপনি যদি ব্যবহারকারীদের কোনো ভূমিকা (role) নির্ধারণ করেন, তাহলে এই নিয়মটি আপনাকে ভূমিকা বা ব্যবহারকারীদের নির্দিষ্ট গোষ্ঠীর উপর ভিত্তি করে অ্যাক্সেস সীমিত করতে দেয়। উদাহরণস্বরূপ, আপনি যদি গ্রেড সংরক্ষণ করেন, তাহলে আপনি 'ছাত্র' গোষ্ঠীকে (শুধুমাত্র তাদের বিষয়বস্তু পড়ার জন্য), 'শিক্ষক' গোষ্ঠীকে (তাদের বিষয়ে পড়া ও লেখার জন্য), এবং 'অধ্যক্ষ' গোষ্ঠীকে (সমস্ত বিষয়বস্তু পড়ার জন্য) বিভিন্ন অ্যাক্সেস স্তর নির্ধারণ করতে পারেন।

যখন এই নিয়মটি কাজ করে না: Realtime Database এবং Cloud Storage , আপনার নিয়মগুলো get() মেথড ব্যবহার করতে পারে না, যা Cloud Firestore নিয়মগুলোতে অন্তর্ভুক্ত করা যায়। ফলস্বরূপ, আপনার নিয়মগুলোতে ব্যবহৃত অ্যাট্রিবিউটগুলো প্রতিফলিত করার জন্য আপনাকে আপনার ডেটাবেস বা ফাইলের মেটাডেটা গঠন করতে হবে।

এই নিয়মটি সেট আপ করতে: Cloud Firestore , আপনার ব্যবহারকারীদের ডকুমেন্টে একটি রিডেবল ফিল্ড অন্তর্ভুক্ত করুন, তারপর সেই ফিল্ডটি রিড করতে এবং শর্তসাপেক্ষে অ্যাক্সেস দেওয়ার জন্য আপনার নিয়মটি তৈরি করুন। Realtime Database , একটি ডেটা পাথ তৈরি করুন যা আপনার অ্যাপের ব্যবহারকারীদের সংজ্ঞায়িত করে এবং একটি চাইল্ড নোডে তাদের একটি রোল প্রদান করে।

এছাড়াও আপনি Authentication কাস্টম ক্লেইম সেট আপ করতে পারেন এবং তারপরে যেকোনো Firebase Security Rules auth.token ভেরিয়েবল থেকে সেই তথ্য পুনরুদ্ধার করতে পারেন।

ডেটা-সংজ্ঞায়িত বৈশিষ্ট্য এবং ভূমিকা

এই নিয়মগুলো শুধুমাত্র Cloud Firestore এবং Realtime Database প্রযোজ্য।

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, Check a boolean `admin` attribute
    allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"
   }
  }
}

{
  "rules": {
    "some_path": {
      "${subpath}": {
        //
        ".write": "root.child('users').child(auth.uid).child('role').val() === 'admin'",
        ".read": true
      }
    }
  }
}

কাস্টম-দাবি বৈশিষ্ট্য এবং ভূমিকা

এই নিয়মগুলো প্রয়োগ করতে, Firebase Authentication এ কাস্টম ক্লেইম সেট আপ করুন এবং তারপর আপনার নিয়মগুলোতে সেই ক্লেইমগুলো ব্যবহার করুন।

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, check for an administrator 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";
   }
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Create a custom claim for each role or group
        // you want to use
        ".write": "auth.uid !== null && auth.token.writer === true",
        ".read": "auth.uid !== null && auth.token.reader === true"
      }
    }
  }
}

service firebase.storage {
  // Allow reads if the group ID in your token matches the file metadata's `owner` property
  // Allow writes if the group ID is in the user's custom token
  match /files/{groupId}/{fileName} {
    allow read: if resource.metadata.owner == request.auth.token.groupId;
    allow write: if request.auth.token.groupId == groupId;
  }
}

ভাড়াটিয়া বৈশিষ্ট্য

এই নিয়মগুলি প্রয়োগ করতে, Google Cloud Identity Platform (GCIP)-এ মাল্টিটেনেন্সি সেট আপ করুন এবং তারপরে আপনার নিয়মগুলিতে টেন্যান্টটি ব্যবহার করুন। নিম্নলিখিত উদাহরণগুলি একটি নির্দিষ্ট টেন্যান্টের ব্যবহারকারীকে লেখার অনুমতি দেয়, যেমন, tenant2-m6tyz

service cloud.firestore {
  match /databases/{database}/documents {
    // For tenant-based access control, check for a tenantID
    allow write: if request.auth.token.firebase.tenant == 'tenant2-m6tyz';
    allow read: true;
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Only allow reads and writes if user belongs to a specific tenant
        ".write": "auth.uid !== null && auth.token.firebase.tenant === 'tenant2-m6tyz'",
        ".read": "auth.uid !== null
      }
    }
  }
}

service firebase.storage {
  // Only allow reads and writes if user belongs to a specific tenant
  match /files/{tenantId}/{fileName} {
    allow read: if request.auth != null;
    allow write: if request.auth.token.firebase.tenant == tenantId;
  }
}