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

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;
    }
  }
}

উন্নয়ন-পরিবেশ বিধি

আপনার অ্যাপে কাজ করার সময়, আপনি আপনার ডেটাতে তুলনামূলকভাবে উন্মুক্ত বা নিরবচ্ছিন্ন অ্যাক্সেস চাইতে পারেন। আপনার অ্যাপটি প্রোডাকশনে স্থাপন করার আগে আপনার 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 অ্যাক্সেস নিশ্চিত বা অস্বীকার করার জন্য আপনার ডাটাবেস বা ফাইলের মেটাডেটা থেকে ডেটার বিরুদ্ধে অনুরোধটি পরীক্ষা করে।

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

যখন এই নিয়মটি কাজ করে না: Realtime Database এবং Cloud Storage -এ, আপনার নিয়মগুলি Cloud Firestore নিয়মগুলি অন্তর্ভুক্ত করতে পারে এমন get() পদ্ধতি ব্যবহার করতে পারে না। ফলস্বরূপ, আপনার নিয়মগুলিতে আপনি যে বৈশিষ্ট্যগুলি ব্যবহার করছেন তা প্রতিফলিত করার জন্য আপনাকে আপনার ডাটাবেস বা ফাইল মেটাডেটা গঠন করতে হবে।

এই নিয়মটি সেট আপ করার জন্য: 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;
  }
}