ক্লাউড ফায়ারস্টোর নিরাপত্তা বিধি গঠন করা

Cloud Firestore Security Rules allow you to control access to documents and collections in your database. The flexible rules syntax allows you to create rules that match anything, from all writes to the entire database to operations on a specific document.

এই নির্দেশিকায় নিরাপত্তা নিয়মের মৌলিক সিনট্যাক্স এবং কাঠামো বর্ণনা করা হয়েছে। সম্পূর্ণ নিয়মসেট তৈরি করতে এই সিনট্যাক্সকে নিরাপত্তা নিয়মের শর্তাবলীর সাথে একত্রিত করুন।

পরিষেবা এবং ডাটাবেস ঘোষণা

Cloud Firestore Security Rules সর্বদা নিম্নলিখিত ঘোষণা দিয়ে শুরু হয়:

service cloud.firestore {
  // The {database} wildcard allows the rules to reference any database,
  // but these rules are only active on databases where they are explicitly deployed.
  match /databases/{database}/documents {
    // ...
  }
}

service cloud.firestore ডিক্লারেশনটি নিয়মগুলোকে Cloud Firestore মধ্যে সীমাবদ্ধ রাখে, ফলে Cloud Firestore Security Rules এবং ক্লাউড স্টোরেজের মতো অন্যান্য প্রোডাক্টের নিয়মের মধ্যে কোনো সংঘাত হয় না।

The match /databases/{database}/documents declaration specifies that rules should match any Cloud Firestore database in the project. While a project can contain up to 100 databases, only the first database created is designated as the default.

আপনার প্রোজেক্টের প্রতিটি নামযুক্ত ডেটাবেসের জন্য Cloud Firestore Security Rules আলাদাভাবে প্রয়োগ করা হয়। এর মানে হলো, আপনি যদি একাধিক ডেটাবেস তৈরি করেন, তবে আপনাকে প্রতিটির জন্য আলাদাভাবে নিয়মগুলি পরিচালনা এবং স্থাপন করতে হবে। আপনার আপডেটগুলি স্থাপন করার বিষয়ে বিস্তারিত নির্দেশাবলীর জন্য, "আপনার আপডেটগুলি স্থাপন করুন" দেখুন।

মৌলিক পঠন/লিখন নিয়মাবলী

মৌলিক নিয়মগুলির মধ্যে একটি match স্টেটমেন্ট থাকে যা একটি ডকুমেন্ট পাথ নির্দিষ্ট করে এবং একটি allow এক্সপ্রেশন থাকে যা বিশদভাবে বর্ণনা করে কখন নির্দিষ্ট ডেটা পড়া অনুমোদিত:

service cloud.firestore {
  match /databases/{database}/documents {

    // Match any document in the 'cities' collection
    match /cities/{city} {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

সমস্ত ম্যাচ স্টেটমেন্ট অবশ্যই ডকুমেন্টকে নির্দেশ করবে, কালেকশনকে নয়। একটি ম্যাচ স্টেটমেন্ট কোনো নির্দিষ্ট ডকুমেন্টকে নির্দেশ করতে পারে, যেমন match /cities/SF , অথবা নির্দিষ্ট পাথের যেকোনো ডকুমেন্টকে নির্দেশ করার জন্য ওয়াইল্ডকার্ড ব্যবহার করতে পারে, যেমন match /cities/{city}

In the example above, the match statement uses the {city} wildcard syntax. This means the rule applies to any document in the cities collection, such as /cities/SF or /cities/NYC . When the allow expressions in the match statement are evaluated, the city variable will resolve to the city document name, such as SF or NYC .

দানাদার কার্যক্রম

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

একটি read রুলকে get এবং list এ ভাগ করা যায়, অপরদিকে একটি write রুলকে create , update এবং delete এ ভাগ করা যায়:

service cloud.firestore {
  match /databases/{database}/documents {
    // A read rule can be divided into get and list rules

    match /cities/{city} {
      // Applies to single document read requests
      allow get: if <condition>;

      // Applies to queries and collection read requests
      allow list: if <condition>;
    }
    // A write rule can be divided into create, update, and delete rules
    match /cities/{city} {
      // Applies to writes to nonexistent documents
      allow create: if <condition>;

      // Applies to writes to existing documents
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
}

শ্রেণিবদ্ধ ডেটা

Cloud Firestore ডেটা ডকুমেন্টের কালেকশন হিসেবে সাজানো থাকে, এবং প্রতিটি ডকুমেন্ট সাব-কালেকশনের মাধ্যমে এই স্তরবিন্যাসকে প্রসারিত করতে পারে। নিরাপত্তা বিধিগুলো স্তরবিন্যাসযুক্ত ডেটার সাথে কীভাবে কাজ করে, তা বোঝা গুরুত্বপূর্ণ।

Consider the situation where each document in the cities collection contains a landmarks subcollection. Security rules apply only at the matched path, so the access controls defined on the cities collection do not apply to the landmarks subcollection. Instead, write explicit rules to control access to subcollections:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      allow read, write: if <condition>;

        // Explicitly define rules for the 'landmarks' subcollection
        match /landmarks/{landmark} {
          allow read, write: if <condition>;
        }
    }
  }
}

যখন match স্টেটমেন্টগুলোকে নেস্ট করা হয়, তখন ভেতরের match স্টেটমেন্টের পাথ সর্বদা বাইরের match স্টেটমেন্টের পাথের সাপেক্ষে আপেক্ষিক হয়। অতএব, নিম্নলিখিত নিয়মসেটগুলো সমতুল্য:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}
service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city}/landmarks/{landmark} {
      allow read, write: if <condition>;
    }
  }
}

পুনরাবৃত্তিমূলক ওয়াইল্ডকার্ড

যদি আপনি যেকোনো গভীরতার স্তরবিন্যাসে নিয়ম প্রয়োগ করতে চান, তাহলে রিকার্সিভ ওয়াইল্ডকার্ড সিনট্যাক্স, {name=**} ব্যবহার করুন। উদাহরণস্বরূপ:

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

রিকার্সিভ ওয়াইল্ডকার্ড সিনট্যাক্স ব্যবহার করার সময়, ওয়াইল্ডকার্ড ভেরিয়েবলটিতে সম্পূর্ণ ম্যাচিং পাথ সেগমেন্টটি থাকবে, এমনকি যদি ডকুমেন্টটি একটি গভীরভাবে নেস্টেড সাবকালেকশনের মধ্যে অবস্থিত থাকে। উদাহরণস্বরূপ, উপরে তালিকাভুক্ত নিয়মগুলি /cities/SF/landmarks/coit_tower এ অবস্থিত একটি ডকুমেন্টের সাথে মিলবে, এবং document ভেরিয়েবলের মান হবে SF/landmarks/coit_tower

তবে মনে রাখবেন যে, রিকার্সিভ ওয়াইল্ডকার্ডের আচরণ নিয়মের সংস্করণের উপর নির্ভর করে।

সংস্করণ ১

নিরাপত্তা নিয়মগুলো ডিফল্টরূপে ভার্সন ১ ব্যবহার করে। ভার্সন ১-এ, রিকার্সিভ ওয়াইল্ডকার্ডগুলো এক বা একাধিক পাথ আইটেমের সাথে মেলে। এগুলো কোনো খালি পাথের সাথে মেলে না, তাই match /cities/{city}/{document=**} সাব-কালেকশনের ডকুমেন্টগুলোর সাথে মেলে কিন্তু cities কালেকশনের ডকুমেন্টগুলোর সাথে মেলে না, যেখানে match /cities/{document=**} cities কালেকশন এবং সাব-কালেকশন উভয়ের ডকুমেন্টগুলোর সাথেই মেলে।

রিকার্সিভ ওয়াইল্ডকার্ড অবশ্যই ম্যাচ স্টেটমেন্টের শেষে আসতে হবে।

সংস্করণ ২

নিরাপত্তা নিয়মের সংস্করণ ২-এ, রিকার্সিভ ওয়াইল্ডকার্ড শূন্য বা তার বেশি পাথ আইটেমকে ম্যাচ করে। match/cities/{city}/{document=**} যেকোনো সাবকালেকশনের ডকুমেন্টের পাশাপাশি cities কালেকশনের ডকুমেন্টগুলোকেও ম্যাচ করে।

আপনার নিরাপত্তা নিয়মের শীর্ষে rules_version = '2'; যোগ করে আপনাকে অবশ্যই সংস্করণ ২ চালু করতে হবে:

rules_version = '2';
service cloud.firestore {
 match /databases/{database}/documents {
   // Matches any document in the cities collection as well as any document
   // in a subcollection.
   match /cities/{city}/{document=**} {
     allow read, write: if <condition>;
   }
 }
}

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

rules_version = '2';
service cloud.firestore {
 match /databases/{database}/documents {
   // Matches any document in the songs collection group
   match /{path=**}/songs/{song} {
     allow read, write: if <condition>;
   }
 }
}

আপনি যদি কালেকশন গ্রুপ কোয়েরি ব্যবহার করেন, তাহলে আপনাকে অবশ্যই ভার্সন ২ ব্যবহার করতে হবে, কালেকশন গ্রুপ কোয়েরি সুরক্ষিতকরণ দেখুন।

ওভারল্যাপিং ম্যাচ স্টেটমেন্ট

একটি ডকুমেন্টের পক্ষে একাধিক match স্টেটমেন্টের সাথে মিলে যাওয়া সম্ভব। যদি একাধিক allow এক্সপ্রেশন একটি রিকোয়েস্টের সাথে মিলে যায়, তবে নিম্নলিখিত শর্তগুলোর মধ্যে যেকোনো একটি true হলে অ্যাক্সেসের অনুমতি দেওয়া হয়:

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the 'cities' collection.
    match /cities/{city} {
      allow read, write: if false;
    }

    // Matches any document in the 'cities' collection or subcollections.
    match /cities/{document=**} {
      allow read, write: if true;
    }
  }
}

উপরের উদাহরণে, cities কালেকশনে সমস্ত রিড এবং রাইট অনুমোদিত হবে, কারণ দ্বিতীয় নিয়মটি সর্বদা true , যদিও প্রথম নিয়মটি সর্বদা false

নিরাপত্তা নিয়মের সীমা

নিরাপত্তা বিধি নিয়ে কাজ করার সময় নিম্নলিখিত সীমাগুলো লক্ষ্য করুন:

সীমা বিস্তারিত
প্রতি অনুরোধে exists() , get() , এবং getAfter() কলের সর্বোচ্চ সংখ্যা
  • একক-ডকুমেন্ট অনুরোধ এবং কোয়েরি অনুরোধের জন্য ১০।
  • একাধিক ডকুমেন্ট রিড, ট্রানজ্যাকশন এবং ব্যাচড রাইটের জন্য ২০। পূর্ববর্তী ১০-এর সীমাটি প্রতিটি অপারেশনের ক্ষেত্রেও প্রযোজ্য।

    উদাহরণস্বরূপ, ধরুন আপনি ৩টি রাইট অপারেশন সহ একটি ব্যাচড রাইট রিকোয়েস্ট তৈরি করেছেন এবং আপনার সিকিউরিটি রুলগুলো প্রতিটি রাইট ভ্যালিডেট করতে ২টি ডকুমেন্ট অ্যাক্সেস কল ব্যবহার করে। এই ক্ষেত্রে, প্রতিটি রাইট তার ১০টি অ্যাক্সেস কলের মধ্যে ২টি ব্যবহার করে এবং ব্যাচড রাইট রিকোয়েস্টটি তার ২০টি অ্যাক্সেস কলের মধ্যে ৬টি ব্যবহার করে।

যেকোনো একটি সীমা অতিক্রম করলে 'অনুমতি নেই' ত্রুটি দেখা দেয়।

কিছু ডকুমেন্ট অ্যাক্সেস কল ক্যাশ করা হতে পারে, এবং ক্যাশ করা কলগুলো সীমার মধ্যে গণনা করা হয় না।

নেস্টেড match স্টেটমেন্টের সর্বোচ্চ গভীরতা ১০
নেস্টেড match স্টেটমেন্টের একটি সেটের মধ্যে অনুমোদিত সর্বোচ্চ পাথ দৈর্ঘ্য, যা পাথ সেগমেন্ট আকারে থাকে। ১০০
নেস্টেড match স্টেটমেন্টের একটি সেটের মধ্যে অনুমোদিত সর্বাধিক সংখ্যক পাথ ক্যাপচার ভেরিয়েবল। ২০
ফাংশন কলের সর্বোচ্চ গভীরতা ২০
ফাংশন আর্গুমেন্টের সর্বোচ্চ সংখ্যা
প্রতি ফাংশনে let ভেরিয়েবল বাইন্ডিংয়ের সর্বোচ্চ সংখ্যা ১০
পুনরাবৃত্তিমূলক বা চক্রাকার ফাংশন কলের সর্বোচ্চ সংখ্যা ০ (অনুমতি নেই)
প্রতি অনুরোধে মূল্যায়ন করা এক্সপ্রেশনের সর্বোচ্চ সংখ্যা ১,০০০
একটি নিয়মাবলীর সর্বোচ্চ আকার নিয়মাবলীকে অবশ্যই দুটি আকারের সীমা মেনে চলতে হবে:
  • Firebase কনসোল থেকে অথবা firebase deploy ব্যবহার করে CLI থেকে প্রকাশিত রুলসেট টেক্সট সোর্সের আকারের উপর ২৫৬ KB-এর একটি সীমা রয়েছে।
  • ফায়ারবেস যখন সোর্স কোড প্রসেস করে এবং ব্যাক-এন্ডে সক্রিয় করে, তখন যে কম্পাইল করা রুলসেট তৈরি হয় তার আকারের উপর ২৫০ কেবি-র একটি সীমা থাকে।

পরবর্তী পদক্ষেপ