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

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

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

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

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 এবং ক্লাউড স্টোরেজের মতো অন্যান্য পণ্যের নিয়মের মধ্যে দ্বন্দ্ব প্রতিরোধ করে।

match /databases/{database}/documents ঘোষণায় উল্লেখ করা হয়েছে যে নিয়মগুলি প্রকল্পের যেকোনো Cloud Firestore ডাটাবেসের সাথে মিলবে। যদিও একটি প্রকল্পে সর্বাধিক ১০০টি ডাটাবেস থাকতে পারে, শুধুমাত্র প্রথম তৈরি করা ডাটাবেসটি ডিফল্ট হিসাবে মনোনীত হয়।

আপনার প্রকল্পের প্রতিটি নামযুক্ত ডাটাবেসের জন্য 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} তে।

উপরের উদাহরণে, ম্যাচ স্টেটমেন্টটি {city} ওয়াইল্ডকার্ড সিনট্যাক্স ব্যবহার করে। এর অর্থ হল এই নিয়মটি cities সংগ্রহের যেকোনো নথির ক্ষেত্রে প্রযোজ্য, যেমন /cities/SF অথবা /cities/NYC । যখন ম্যাচ স্টেটমেন্টে allow এক্সপ্রেশনগুলি মূল্যায়ন করা হয়, তখন city ভেরিয়েবলটি শহরের নথির নাম, যেমন SF অথবা 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 ডেটা বিভিন্ন নথির সংগ্রহে সংগঠিত হয় এবং প্রতিটি নথি উপ-সংগ্রহের মাধ্যমে শ্রেণিবিন্যাস প্রসারিত করতে পারে। নিরাপত্তা নিয়মগুলি কীভাবে শ্রেণিবিন্যাস ডেটার সাথে ইন্টারঅ্যাক্ট করে তা বোঝা গুরুত্বপূর্ণ।

cities সংগ্রহের প্রতিটি নথিতে একটি landmarks উপ-সংগ্রহ রয়েছে এমন পরিস্থিতি বিবেচনা করুন। সুরক্ষা নিয়মগুলি কেবল মিলিত পথে প্রযোজ্য, তাই cities সংগ্রহে সংজ্ঞায়িত অ্যাক্সেস নিয়ন্ত্রণগুলি landmarks উপ-সংগ্রহের ক্ষেত্রে প্রযোজ্য নয়। পরিবর্তে, উপ-সংগ্রহগুলিতে অ্যাক্সেস নিয়ন্ত্রণ করার জন্য স্পষ্ট নিয়মগুলি লিখুন:

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'; যোগ করে আপনাকে সংস্করণ 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>;
    }
  }
}

যদি আপনি সংগ্রহ গোষ্ঠীর প্রশ্ন ব্যবহার করেন, তাহলে আপনাকে অবশ্যই সংস্করণ 2 ব্যবহার করতে হবে, সংগ্রহ গোষ্ঠীর প্রশ্নগুলি সুরক্ষিত করা দেখুন।

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

একটি ডকুমেন্টের একাধিক 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() কল
  • একক-নথি অনুরোধ এবং কোয়েরি অনুরোধের জন্য ১০।
  • মাল্টি-ডকুমেন্ট রিড, লেনদেন এবং ব্যাচড রাইটসের জন্য ২০। পূর্ববর্তী ১০ এর সীমা প্রতিটি অপারেশনের ক্ষেত্রেও প্রযোজ্য।

    উদাহরণস্বরূপ, কল্পনা করুন আপনি 3টি লেখার অপারেশন সহ একটি ব্যাচড লেখার অনুরোধ তৈরি করেছেন এবং আপনার সুরক্ষা নিয়ম প্রতিটি লেখা যাচাই করার জন্য 2টি ডকুমেন্ট অ্যাক্সেস কল ব্যবহার করে। এই ক্ষেত্রে, প্রতিটি লেখা তার 10টি অ্যাক্সেস কলের মধ্যে 2টি ব্যবহার করে এবং ব্যাচড লেখার অনুরোধ তার 20টি অ্যাক্সেস কলের মধ্যে 6টি ব্যবহার করে।

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

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

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

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