নিরাপত্তা নিয়মের ভাষা

Cloud Firestore

Cloud Firestore এবং Cloud Storage Firebase Security Rules নিম্নলিখিত কাঠামো এবং সিনট্যাক্স ব্যবহার করে:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

আপনি নিয়ম তৈরি করার সময় নিম্নলিখিত মূল ধারণাগুলি বোঝা গুরুত্বপূর্ণ:

• অনুরোধ: allow বিবৃতিতে আমন্ত্রিত পদ্ধতি বা পদ্ধতি। এই পদ্ধতিগুলি আপনি চালানোর অনুমতি দিচ্ছেন। স্ট্যান্ডার্ড পদ্ধতি হল: get , list , create , update , and delete . read এবং write সুবিধার পদ্ধতিগুলি নির্দিষ্ট ডাটাবেস বা স্টোরেজ পাথে বিস্তৃত পঠন এবং লেখার অ্যাক্সেস সক্ষম করে।
• পাথ: ডাটাবেস বা স্টোরেজ অবস্থান, একটি URI পাথ হিসাবে উপস্থাপিত।
• নিয়ম: allow বিবৃতি, যার মধ্যে এমন একটি শর্ত রয়েছে যা একটি অনুরোধের অনুমতি দেয় যদি এটি সত্যে মূল্যায়ন করে।

এই ধারণাগুলির প্রতিটি নীচে আরও বিশদে বর্ণনা করা হয়েছে।

Cloud Storage

Cloud Firestore এবং Cloud Storage Firebase Security Rules নিম্নলিখিত কাঠামো এবং সিনট্যাক্স ব্যবহার করে:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

আপনি নিয়ম তৈরি করার সময় নিম্নলিখিত মূল ধারণাগুলি বোঝা গুরুত্বপূর্ণ:

• অনুরোধ: allow বিবৃতিতে আমন্ত্রিত পদ্ধতি বা পদ্ধতি। এই পদ্ধতিগুলি আপনি চালানোর অনুমতি দিচ্ছেন। স্ট্যান্ডার্ড পদ্ধতি হল: get , list , create , update , and delete . read এবং write সুবিধার পদ্ধতিগুলি নির্দিষ্ট ডাটাবেস বা স্টোরেজ পাথে বিস্তৃত পঠন এবং লেখার অ্যাক্সেস সক্ষম করে।
• পাথ: ডাটাবেস বা স্টোরেজ অবস্থান, একটি URI পাথ হিসাবে উপস্থাপিত।
• নিয়ম: allow বিবৃতি, যার মধ্যে এমন একটি শর্ত রয়েছে যা একটি অনুরোধের অনুমতি দেয় যদি এটি সত্যে মূল্যায়ন করে।

এই ধারণাগুলির প্রতিটি নীচে আরও বিশদে বর্ণনা করা হয়েছে।

Realtime Database

Realtime Database , Firebase Security Rules একটি JSON নথিতে থাকা JavaScript-এর মতো অভিব্যক্তিগুলি নিয়ে গঠিত।

তারা নিম্নলিখিত সিনট্যাক্স ব্যবহার করে:

{
  "rules": {
    "<<path>>": {
    // Allow the request if the condition for each method is true.
      ".read": <<condition>>,
      ".write": <<condition>>,
      ".validate": <<condition>>
    }
  }
}

নিয়মের তিনটি মৌলিক উপাদান রয়েছে:

• পাথ: ডাটাবেসের অবস্থান। এটি আপনার ডাটাবেসের JSON গঠনকে মিরর করে।
• অনুরোধ: এই পদ্ধতিগুলি নিয়ম অ্যাক্সেস মঞ্জুর করতে ব্যবহার করে৷ read এবং write নিয়মগুলি বিস্তৃত পঠন এবং লেখার অ্যাক্সেস মঞ্জুর করে, যখন validate নিয়মগুলি ইনকামিং বা বিদ্যমান ডেটার উপর ভিত্তি করে অ্যাক্সেস মঞ্জুর করার জন্য একটি গৌণ যাচাইকরণ হিসাবে কাজ করে।
• শর্ত: এমন শর্ত যা একটি অনুরোধের অনুমতি দেয় যদি এটি সত্যে মূল্যায়ন করে।

Cloud Firestore

Cloud Firestore এবং Cloud Storage একটি নিয়মের মৌলিক উপাদানগুলি নিম্নরূপ:

• service ঘোষণা: ফায়ারবেস পণ্যের জন্য নিয়ম প্রযোজ্য বলে ঘোষণা করে।
• match ব্লক: নিয়ম প্রযোজ্য ডাটাবেস বা স্টোরেজ বাকেটের একটি পথ সংজ্ঞায়িত করে।
• allow বিবৃতি: পদ্ধতি দ্বারা পৃথক, অ্যাক্সেস প্রদানের জন্য শর্ত প্রদান করে। সমর্থিত পদ্ধতিগুলির মধ্যে রয়েছে: get , list , create , update , delete এবং সুবিধার পদ্ধতিগুলি read এবং write ৷
• ঐচ্ছিক function ঘোষণা: একাধিক নিয়ম জুড়ে ব্যবহারের জন্য শর্ত একত্রিত এবং মোড়ানোর ক্ষমতা প্রদান করুন।

service allow বিবৃতি সহ এক বা একাধিক match ব্লক রয়েছে যা অনুরোধগুলিতে অ্যাক্সেস দেওয়ার শর্ত প্রদান করে। request এবং resource ভেরিয়েবল নিয়ম শর্তে ব্যবহারের জন্য উপলব্ধ. Firebase Security Rules ল্যাঙ্গুয়েজ function ডিক্লেয়ারেশনকেও সমর্থন করে।

সিনট্যাক্স সংস্করণ

syntax বিবৃতি সূত্র লিখতে ব্যবহৃত Firebase নিয়ম ভাষার সংস্করণ নির্দেশ করে। ভাষার সর্বশেষ সংস্করণ v2 ।

rules_version = '2';
service cloud.firestore {
...
}

কোনো rules_version বিবৃতি সরবরাহ করা না হলে, v1 ইঞ্জিন ব্যবহার করে আপনার নিয়মগুলি মূল্যায়ন করা হবে।

সেবা

service ঘোষণায় আপনার নিয়মগুলি প্রযোজ্য Firebase পণ্য বা পরিষেবাটি নির্ধারণ করে৷ আপনি উৎস ফাইল প্রতি শুধুমাত্র একটি service ঘোষণা অন্তর্ভুক্ত করতে পারেন.

service cloud.firestore {
 // Your 'match' blocks with their corresponding 'allow' statements and
 // optional 'function' declarations are contained here
}

service firebase.storage {
  // Your 'match' blocks with their corresponding 'allow' statements and
  // optional 'function' declarations are contained here
}

আপনি যদি Firebase CLI ব্যবহার করে Cloud Firestore এবং Cloud Storage উভয়ের জন্য নিয়মগুলি সংজ্ঞায়িত করেন তবে আপনাকে সেগুলি আলাদা ফাইলে বজায় রাখতে হবে৷

ম্যাচ

একটি match ব্লক একটি path প্যাটার্ন ঘোষণা করে যা অনুরোধকৃত অপারেশনের জন্য পাথের সাথে মিলে যায় (আগত request.path )। match মূল অংশে এক বা একাধিক নেস্টেড match ব্লক থাকতে হবে, বিবৃতি বা function ঘোষণার allow । নেস্টেড match ব্লকের পাথ প্যারেন্ট match ব্লকের পাথের সাথে আপেক্ষিক।

path প্যাটার্ন হল একটি ডিরেক্টরির মতো নাম যাতে ভেরিয়েবল বা ওয়াইল্ডকার্ড থাকতে পারে। path প্যাটার্ন একক-পাথ সেগমেন্ট এবং মাল্টি-পাথ সেগমেন্ট মিলের অনুমতি দেয়। একটি path আবদ্ধ যেকোন ভেরিয়েবলগুলি match স্কোপের মধ্যে দৃশ্যমান হয় বা যে কোনও নেস্টেড স্কোপ যেখানে path ঘোষণা করা হয়।

একটি path প্যাটার্নের সাথে মিলগুলি আংশিক বা সম্পূর্ণ হতে পারে:

• আংশিক মিল: path প্যাটার্ন হল request.path এর একটি উপসর্গ-মিল।
• সম্পূর্ণ মিল: path প্যাটার্ন সমগ্র request.path সাথে মেলে।

একটি সম্পূর্ণ মিল তৈরি হলে ব্লকের মধ্যে নিয়মগুলি মূল্যায়ন করা হয়। যখন একটি আংশিক ম্যাচ করা হয় তখন নেস্টেড match নিয়মগুলি পরীক্ষা করা হয় যে কোনও নেস্টেড path ম্যাচটি সম্পূর্ণ করবে কিনা।

অনুরোধের অনুমতি দেওয়া হবে কিনা তা নির্ধারণ করতে প্রতিটি সম্পূর্ণ match নিয়মগুলি মূল্যায়ন করা হয়। কোনো মিলিত নিয়ম অ্যাক্সেস মঞ্জুর করলে, অনুরোধ অনুমোদিত হয়. যদি কোন মিলিত নিয়ম অ্যাক্সেস মঞ্জুর করে, অনুরোধ অস্বীকার করা হয়.

// Given request.path == /example/hello/nested/path the following
// declarations indicate whether they are a partial or complete match and
// the value of any variables visible within the scope.
service firebase.storage {
  // Partial match.
  match /example/{singleSegment} {   // `singleSegment` == 'hello'
    allow write;                     // Write rule not evaluated.
    // Complete match.
    match /nested/path {             // `singleSegment` visible in scope.
      allow read;                    // Read rule is evaluated.
    }
  }
  // Complete match.
  match /example/{multiSegment=**} { // `multiSegment` == /hello/nested/path
    allow read;                      // Read rule is evaluated.
  }
}

উপরের উদাহরণটি দেখায়, path ঘোষণা নিম্নলিখিত ভেরিয়েবলগুলিকে সমর্থন করে:

• একক-সেগমেন্ট ওয়াইল্ডকার্ড: একটি ওয়াইল্ডকার্ড ভেরিয়েবলকে একটি পাথে ঘোষণা করা হয় একটি ভেরিয়েবলকে কোঁকড়া বন্ধনীতে মোড়ানো: {variable} । এই ভেরিয়েবলটি একটি string হিসাবে match স্টেটমেন্টের মধ্যে অ্যাক্সেসযোগ্য।
• রিকার্সিভ ওয়াইল্ডকার্ড: রিকার্সিভ, বা মাল্টি-সেগমেন্ট, ওয়াইল্ডকার্ড একটি পাথে বা নীচে একাধিক পাথ সেগমেন্টের সাথে মেলে। এই ওয়াইল্ডকার্ডটি আপনার সেট করা অবস্থানের নীচের সমস্ত পথের সাথে মেলে৷ আপনি আপনার সেগমেন্ট ভেরিয়েবলের শেষে =** স্ট্রিং যোগ করে এটি ঘোষণা করতে পারেন: {variable=**} । এই ভেরিয়েবলটি একটি path অবজেক্ট হিসাবে match স্টেটমেন্টের মধ্যে অ্যাক্সেসযোগ্য।

অনুমতি দিন

match ব্লকে এক বা একাধিক allow বিবৃতি রয়েছে। এগুলি আপনার আসল নিয়ম। আপনি এক বা একাধিক পদ্ধতিতে allow বিধি প্রয়োগ করতে পারেন। Cloud Firestore বা Cloud Storage যেকোনও ইনকামিং অনুরোধ মঞ্জুর করার জন্য একটি allow বিবৃতির শর্তগুলিকে সত্য বলে মূল্যায়ন করতে হবে। আপনি শর্ত ছাড়া allow বিবৃতিও লিখতে পারেন, উদাহরণস্বরূপ, allow read । যদি allow বিবৃতিতে একটি শর্ত অন্তর্ভুক্ত না থাকে, তবে, এটি সর্বদা সেই পদ্ধতির অনুরোধের অনুমতি দেয়।

যদি পদ্ধতির জন্য allow নিয়মগুলির কোনোটি সন্তুষ্ট হয়, অনুরোধটি অনুমোদিত। অতিরিক্তভাবে, যদি একটি বৃহত্তর নিয়ম অ্যাক্সেস মঞ্জুর করে, Rules অ্যাক্সেস মঞ্জুর করে এবং অ্যাক্সেসকে সীমিত করতে পারে এমন আরও কোনো দানাদার নিয়ম উপেক্ষা করে।

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

service firebase.storage {
  // Allow the requestor to read or delete any resource on a path under the
  // user directory.
  match /users/{userId}/{anyUserFile=**} {
    allow read, delete: if request.auth != null && request.auth.uid == userId;
  }

  // Allow the requestor to create or update their own images.
  // When 'request.method' == 'delete' this rule and the one matching
  // any path under the user directory would both match and the `delete`
  // would be permitted.

  match /users/{userId}/images/{imageId} {
    // Whether to permit the request depends on the logical OR of all
    // matched rules. This means that even if this rule did not explicitly
    // allow the 'delete' the earlier rule would have.
    allow write: if request.auth != null && request.auth.uid == userId && imageId.matches('*.png');
  }
}

পদ্ধতি

প্রতিটি allow বিবৃতিতে একটি পদ্ধতি রয়েছে যা একই পদ্ধতির আগত অনুরোধগুলির জন্য অ্যাক্সেস মঞ্জুর করে।

আপনি একই match ব্লকে পঠিত পদ্ধতিগুলিকে ওভারল্যাপ করতে পারবেন না বা একই path ঘোষণায় বিরোধপূর্ণ লেখার পদ্ধতিগুলিকে ওভারল্যাপ করতে পারবেন না৷

উদাহরণস্বরূপ, নিম্নলিখিত নিয়মগুলি ব্যর্থ হবে:

service bad.example {
  match /rules/with/overlapping/methods {
    // This rule allows reads to all authenticated users
    allow read: if request.auth != null;

    match another/subpath {
      // This secondary, more specific read rule causes an error
      allow get: if request.auth != null && request.auth.uid == "me";
      // Overlapping write methods in the same path cause an error as well
      allow write: if request.auth != null;
      allow create: if request.auth != null && request.auth.uid == "me";
    }
  }
}

ফাংশন

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

• ফাংশনে শুধুমাত্র একটি return স্টেটমেন্ট থাকতে পারে। তারা কোন অতিরিক্ত যুক্তি ধারণ করতে পারে না. উদাহরণস্বরূপ, তারা লুপ চালাতে পারে না বা বহিরাগত পরিষেবাগুলিকে কল করতে পারে না।
• ফাংশনগুলি স্বয়ংক্রিয়ভাবে ফাংশন এবং ভেরিয়েবলগুলিকে যে সুযোগে সংজ্ঞায়িত করা হয়েছে তা থেকে অ্যাক্সেস করতে পারে। উদাহরণস্বরূপ, service cloud.firestore স্কোপের মধ্যে সংজ্ঞায়িত একটি ফাংশন resource ভেরিয়েবল এবং বিল্ট-ইন ফাংশন যেমন get() এবং exists() অ্যাক্সেস করতে পারে।
• ফাংশন অন্যান্য ফাংশন কল করতে পারে কিন্তু পুনরাবৃত্তি নাও হতে পারে। মোট কল স্ট্যাকের গভীরতা 20-এর মধ্যে সীমাবদ্ধ।
• নিয়ম সংস্করণ v2 , ফাংশন let কীওয়ার্ড ব্যবহার করে ভেরিয়েবলকে সংজ্ঞায়িত করতে পারে। ফাংশনে 10 পর্যন্ত লেট বাইন্ডিং থাকতে পারে, কিন্তু একটি রিটার্ন স্টেটমেন্ট দিয়ে শেষ করতে হবে।

একটি ফাংশন function কীওয়ার্ড দিয়ে সংজ্ঞায়িত করা হয় এবং শূন্য বা তার বেশি আর্গুমেন্ট নেয়। উদাহরণস্বরূপ, আপনি একটি একক ফাংশনে উপরের উদাহরণগুলিতে ব্যবহৃত দুটি ধরণের শর্ত একত্রিত করতে চাইতে পারেন:

service cloud.firestore {
  match /databases/{database}/documents {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }

    match /cities/{city} {
      allow read, write: if signedInOrPublic();
    }

    match /users/{user} {
      allow read, write: if signedInOrPublic();
    }
  }
}

এখানে ফাংশন আর্গুমেন্ট এবং লেট অ্যাসাইনমেন্ট দেখানোর একটি উদাহরণ। অ্যাসাইনমেন্ট স্টেটমেন্ট সেমি-কোলন দ্বারা আলাদা করা আবশ্যক।

function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  let isAdmin = exists(/databases/$(database)/documents/admins/$(userId));
  return isAuthor || isAdmin;
}

লক্ষ্য করুন কিভাবে isAdmin অ্যাসাইনমেন্ট প্রশাসক সংগ্রহের একটি লুকআপ প্রয়োগ করে। অপ্রয়োজনীয় লুকআপের প্রয়োজন ছাড়াই অলস মূল্যায়নের জন্য, && (AND) এবং || এর শর্ট-সার্কিট প্রকৃতির সুবিধা নিন। (অথবা) একটি দ্বিতীয় ফাংশন কল করার জন্য তুলনা শুধুমাত্র যদি isAuthor সত্য ( && তুলনার জন্য) বা মিথ্যা ( || তুলনার জন্য) দেখানো হয়।

function isAdmin(userId) {
  return exists(/databases/$(database)/documents/admins/$(userId));
}
function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  // `||` is short-circuiting; isAdmin called only if isAuthor == false.
  return isAuthor || isAdmin(userId);
}

আপনার নিরাপত্তা নিয়মে ফাংশন ব্যবহার করা আপনার নিয়মের জটিলতা বাড়ার সাথে সাথে সেগুলিকে আরও রক্ষণাবেক্ষণযোগ্য করে তোলে।

Cloud Storage

Cloud Firestore এবং Cloud Storage একটি নিয়মের মৌলিক উপাদানগুলি নিম্নরূপ:

• service ঘোষণা: ফায়ারবেস পণ্যের জন্য নিয়ম প্রযোজ্য বলে ঘোষণা করে।
• match ব্লক: নিয়ম প্রযোজ্য ডাটাবেস বা স্টোরেজ বাকেটের একটি পথ সংজ্ঞায়িত করে।
• allow বিবৃতি: পদ্ধতি দ্বারা পৃথক, অ্যাক্সেস প্রদানের জন্য শর্ত প্রদান করে। সমর্থিত পদ্ধতিগুলির মধ্যে রয়েছে: get , list , create , update , delete এবং সুবিধার পদ্ধতিগুলি read এবং write ৷
• ঐচ্ছিক function ঘোষণা: একাধিক নিয়ম জুড়ে ব্যবহারের জন্য শর্ত একত্রিত এবং মোড়ানোর ক্ষমতা প্রদান করুন।

service allow বিবৃতি সহ এক বা একাধিক match ব্লক রয়েছে যা অনুরোধগুলিতে অ্যাক্সেস দেওয়ার শর্ত প্রদান করে। request এবং resource ভেরিয়েবল নিয়ম শর্তে ব্যবহারের জন্য উপলব্ধ. Firebase Security Rules ল্যাঙ্গুয়েজ function ডিক্লেয়ারেশনকেও সমর্থন করে।

সিনট্যাক্স সংস্করণ

syntax বিবৃতি সূত্র লিখতে ব্যবহৃত Firebase নিয়ম ভাষার সংস্করণ নির্দেশ করে। ভাষার সর্বশেষ সংস্করণ v2 ।

rules_version = '2';
service cloud.firestore {
...
}

কোনো rules_version বিবৃতি সরবরাহ করা না হলে, v1 ইঞ্জিন ব্যবহার করে আপনার নিয়মগুলি মূল্যায়ন করা হবে।

সেবা

service ঘোষণায় আপনার নিয়মগুলি প্রযোজ্য Firebase পণ্য বা পরিষেবাটি নির্ধারণ করে৷ আপনি উৎস ফাইল প্রতি শুধুমাত্র একটি service ঘোষণা অন্তর্ভুক্ত করতে পারেন.

service cloud.firestore {
 // Your 'match' blocks with their corresponding 'allow' statements and
 // optional 'function' declarations are contained here
}

service firebase.storage {
  // Your 'match' blocks with their corresponding 'allow' statements and
  // optional 'function' declarations are contained here
}

আপনি যদি Firebase CLI ব্যবহার করে Cloud Firestore এবং Cloud Storage উভয়ের জন্য নিয়মগুলি সংজ্ঞায়িত করেন তবে আপনাকে সেগুলি আলাদা ফাইলে বজায় রাখতে হবে৷

ম্যাচ

একটি match ব্লক একটি path প্যাটার্ন ঘোষণা করে যা অনুরোধকৃত অপারেশনের জন্য পাথের সাথে মিলে যায় (আগত request.path )। match মূল অংশে এক বা একাধিক নেস্টেড match ব্লক থাকতে হবে, বিবৃতি বা function ঘোষণার allow । নেস্টেড match ব্লকের পাথ প্যারেন্ট match ব্লকের পাথের সাথে আপেক্ষিক।

path প্যাটার্ন হল একটি ডিরেক্টরির মতো নাম যাতে ভেরিয়েবল বা ওয়াইল্ডকার্ড থাকতে পারে। path প্যাটার্ন একক-পাথ সেগমেন্ট এবং মাল্টি-পাথ সেগমেন্ট মিলের অনুমতি দেয়। একটি path আবদ্ধ যেকোন ভেরিয়েবলগুলি match স্কোপের মধ্যে দৃশ্যমান হয় বা যে কোনও নেস্টেড স্কোপ যেখানে path ঘোষণা করা হয়।

একটি path প্যাটার্নের সাথে মিলগুলি আংশিক বা সম্পূর্ণ হতে পারে:

• আংশিক মিল: path প্যাটার্ন হল request.path এর একটি উপসর্গ-মিল।
• সম্পূর্ণ মিল: path প্যাটার্ন সমগ্র request.path সাথে মেলে।

একটি সম্পূর্ণ মিল তৈরি হলে ব্লকের মধ্যে নিয়মগুলি মূল্যায়ন করা হয়। যখন একটি আংশিক ম্যাচ করা হয় তখন নেস্টেড match নিয়মগুলি পরীক্ষা করা হয় যে কোনও নেস্টেড path ম্যাচটি সম্পূর্ণ করবে কিনা।

অনুরোধের অনুমতি দেওয়া হবে কিনা তা নির্ধারণ করতে প্রতিটি সম্পূর্ণ match নিয়মগুলি মূল্যায়ন করা হয়। কোনো মিলিত নিয়ম অ্যাক্সেস মঞ্জুর করলে, অনুরোধ অনুমোদিত হয়. যদি কোন মিলিত নিয়ম অ্যাক্সেস মঞ্জুর করে, অনুরোধ অস্বীকার করা হয়.

// Given request.path == /example/hello/nested/path the following
// declarations indicate whether they are a partial or complete match and
// the value of any variables visible within the scope.
service firebase.storage {
  // Partial match.
  match /example/{singleSegment} {   // `singleSegment` == 'hello'
    allow write;                     // Write rule not evaluated.
    // Complete match.
    match /nested/path {             // `singleSegment` visible in scope.
      allow read;                    // Read rule is evaluated.
    }
  }
  // Complete match.
  match /example/{multiSegment=**} { // `multiSegment` == /hello/nested/path
    allow read;                      // Read rule is evaluated.
  }
}

উপরের উদাহরণটি দেখায়, path ঘোষণা নিম্নলিখিত ভেরিয়েবলগুলিকে সমর্থন করে:

• একক-সেগমেন্ট ওয়াইল্ডকার্ড: একটি ওয়াইল্ডকার্ড ভেরিয়েবলকে একটি পাথে ঘোষণা করা হয় একটি ভেরিয়েবলকে কোঁকড়া বন্ধনীতে মোড়ানো: {variable} । এই ভেরিয়েবলটি একটি string হিসাবে match স্টেটমেন্টের মধ্যে অ্যাক্সেসযোগ্য।
• রিকার্সিভ ওয়াইল্ডকার্ড: রিকার্সিভ, বা মাল্টি-সেগমেন্ট, ওয়াইল্ডকার্ড একটি পাথে বা নীচে একাধিক পাথ সেগমেন্টের সাথে মেলে। এই ওয়াইল্ডকার্ডটি আপনার সেট করা অবস্থানের নীচের সমস্ত পথের সাথে মেলে৷ আপনি আপনার সেগমেন্ট ভেরিয়েবলের শেষে =** স্ট্রিং যোগ করে এটি ঘোষণা করতে পারেন: {variable=**} । এই ভেরিয়েবলটি একটি path অবজেক্ট হিসাবে match স্টেটমেন্টের মধ্যে অ্যাক্সেসযোগ্য।

অনুমতি দিন

match ব্লকে এক বা একাধিক allow বিবৃতি রয়েছে। এগুলি আপনার আসল নিয়ম। আপনি এক বা একাধিক পদ্ধতিতে allow বিধি প্রয়োগ করতে পারেন। Cloud Firestore বা Cloud Storage যেকোনও ইনকামিং অনুরোধ মঞ্জুর করার জন্য একটি allow বিবৃতির শর্তগুলিকে সত্য বলে মূল্যায়ন করতে হবে। আপনি শর্ত ছাড়া allow বিবৃতিও লিখতে পারেন, উদাহরণস্বরূপ, allow read । যদি allow বিবৃতিতে একটি শর্ত অন্তর্ভুক্ত না থাকে, তবে, এটি সর্বদা সেই পদ্ধতির অনুরোধের অনুমতি দেয়।

যদি পদ্ধতির জন্য allow নিয়মগুলির কোনোটি সন্তুষ্ট হয়, অনুরোধটি অনুমোদিত। অতিরিক্তভাবে, যদি একটি বৃহত্তর নিয়ম অ্যাক্সেস মঞ্জুর করে, Rules অ্যাক্সেস মঞ্জুর করে এবং অ্যাক্সেসকে সীমিত করতে পারে এমন আরও কোনো দানাদার নিয়ম উপেক্ষা করে।

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

service firebase.storage {
  // Allow the requestor to read or delete any resource on a path under the
  // user directory.
  match /users/{userId}/{anyUserFile=**} {
    allow read, delete: if request.auth != null && request.auth.uid == userId;
  }

  // Allow the requestor to create or update their own images.
  // When 'request.method' == 'delete' this rule and the one matching
  // any path under the user directory would both match and the `delete`
  // would be permitted.

  match /users/{userId}/images/{imageId} {
    // Whether to permit the request depends on the logical OR of all
    // matched rules. This means that even if this rule did not explicitly
    // allow the 'delete' the earlier rule would have.
    allow write: if request.auth != null && request.auth.uid == userId && imageId.matches('*.png');
  }
}

পদ্ধতি

প্রতিটি allow বিবৃতিতে একটি পদ্ধতি রয়েছে যা একই পদ্ধতির আগত অনুরোধগুলির জন্য অ্যাক্সেস মঞ্জুর করে।

আপনি একই match ব্লকে পঠিত পদ্ধতিগুলিকে ওভারল্যাপ করতে পারবেন না বা একই path ঘোষণায় বিরোধপূর্ণ লেখার পদ্ধতিগুলিকে ওভারল্যাপ করতে পারবেন না৷

উদাহরণস্বরূপ, নিম্নলিখিত নিয়মগুলি ব্যর্থ হবে:

service bad.example {
  match /rules/with/overlapping/methods {
    // This rule allows reads to all authenticated users
    allow read: if request.auth != null;

    match another/subpath {
      // This secondary, more specific read rule causes an error
      allow get: if request.auth != null && request.auth.uid == "me";
      // Overlapping write methods in the same path cause an error as well
      allow write: if request.auth != null;
      allow create: if request.auth != null && request.auth.uid == "me";
    }
  }
}

ফাংশন

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

• ফাংশনে শুধুমাত্র একটি return স্টেটমেন্ট থাকতে পারে। তারা কোন অতিরিক্ত যুক্তি ধারণ করতে পারে না. উদাহরণস্বরূপ, তারা লুপ চালাতে পারে না বা বহিরাগত পরিষেবাগুলিকে কল করতে পারে না।
• ফাংশনগুলি স্বয়ংক্রিয়ভাবে ফাংশন এবং ভেরিয়েবলগুলিকে যে সুযোগে সংজ্ঞায়িত করা হয়েছে তা থেকে অ্যাক্সেস করতে পারে। উদাহরণস্বরূপ, service cloud.firestore স্কোপের মধ্যে সংজ্ঞায়িত একটি ফাংশন resource ভেরিয়েবল এবং বিল্ট-ইন ফাংশন যেমন get() এবং exists() অ্যাক্সেস করতে পারে।
• ফাংশন অন্যান্য ফাংশন কল করতে পারে কিন্তু পুনরাবৃত্তি নাও হতে পারে। মোট কল স্ট্যাকের গভীরতা 20-এর মধ্যে সীমাবদ্ধ।
• নিয়ম সংস্করণ v2 , ফাংশন let কীওয়ার্ড ব্যবহার করে ভেরিয়েবলকে সংজ্ঞায়িত করতে পারে। ফাংশনে 10 পর্যন্ত লেট বাইন্ডিং থাকতে পারে, কিন্তু একটি রিটার্ন স্টেটমেন্ট দিয়ে শেষ করতে হবে।

একটি ফাংশন function কীওয়ার্ড দিয়ে সংজ্ঞায়িত করা হয় এবং শূন্য বা তার বেশি আর্গুমেন্ট নেয়। উদাহরণস্বরূপ, আপনি একটি একক ফাংশনে উপরের উদাহরণগুলিতে ব্যবহৃত দুটি ধরণের শর্ত একত্রিত করতে চাইতে পারেন:

service cloud.firestore {
  match /databases/{database}/documents {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }

    match /cities/{city} {
      allow read, write: if signedInOrPublic();
    }

    match /users/{user} {
      allow read, write: if signedInOrPublic();
    }
  }
}

এখানে ফাংশন আর্গুমেন্ট এবং লেট অ্যাসাইনমেন্ট দেখানোর একটি উদাহরণ। অ্যাসাইনমেন্ট স্টেটমেন্ট সেমি-কোলন দ্বারা আলাদা করা আবশ্যক।

function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  let isAdmin = exists(/databases/$(database)/documents/admins/$(userId));
  return isAuthor || isAdmin;
}

লক্ষ্য করুন কিভাবে isAdmin অ্যাসাইনমেন্ট প্রশাসক সংগ্রহের একটি লুকআপ প্রয়োগ করে। অপ্রয়োজনীয় লুকআপের প্রয়োজন ছাড়াই অলস মূল্যায়নের জন্য, && (AND) এবং || এর শর্ট-সার্কিট প্রকৃতির সুবিধা নিন। (অথবা) একটি দ্বিতীয় ফাংশন কল করার জন্য তুলনা শুধুমাত্র যদি isAuthor সত্য ( && তুলনার জন্য) বা মিথ্যা ( || তুলনার জন্য) দেখানো হয়।

function isAdmin(userId) {
  return exists(/databases/$(database)/documents/admins/$(userId));
}
function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  // `||` is short-circuiting; isAdmin called only if isAuthor == false.
  return isAuthor || isAdmin(userId);
}

আপনার নিরাপত্তা নিয়মে ফাংশন ব্যবহার করা আপনার নিয়মের জটিলতা বাড়ার সাথে সাথে সেগুলিকে আরও রক্ষণাবেক্ষণযোগ্য করে তোলে।

Realtime Database

উপরে উল্লিখিত হিসাবে, Realtime Database Rules তিনটি মৌলিক উপাদান রয়েছে: ডাটাবেসের JSON কাঠামোর মিরর হিসাবে ডাটাবেসের অবস্থান, অনুরোধের ধরন এবং অ্যাক্সেস দেওয়ার শর্ত।

ডাটাবেস অবস্থান

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

  {
    "messages": {
      "message0": {
        "content": "Hello",
        "timestamp": 1405704370369
      },
      "message1": {
        "content": "Goodbye",
        "timestamp": 1405704395231
      },
      ...
    }
  }

আপনার নিয়ম যে কাঠামো মিরর করা উচিত. যেমন:

  {
    "rules": {
      "messages": {
        "$message": {
          // only messages from the last ten minutes can be read
          ".read": "data.child('timestamp').val() > (now - 600000)",

          // new messages must have a string content and a number timestamp
          ".validate": "newData.hasChildren(['content', 'timestamp']) &&
                        newData.child('content').isString() &&
                        newData.child('timestamp').isNumber()"
        }
      }
    }
  }

উপরের উদাহরণটি দেখায়, Realtime Database Rules পাথের অংশগুলিকে মেলানোর জন্য একটি $location পরিবর্তনশীলকে সমর্থন করে। পাথের পাশে থাকা যেকোনো চাইল্ড নোডের সাথে আপনার নিয়ম মেলে আপনার পাথ সেগমেন্টের সামনে $ উপসর্গ ব্যবহার করুন।

  {
    "rules": {
      "rooms": {
        // This rule applies to any child of /rooms/, the key for each room id
        // is stored inside $room_id variable for reference
        "$room_id": {
          "topic": {
            // The room's topic can be changed if the room id has "public" in it
            ".write": "$room_id.contains('public')"
          }
        }
      }
    }
  }

আপনি ধ্রুবক পাথ নামের সাথে সমান্তরালে $variable ব্যবহার করতে পারেন।

  {
    "rules": {
      "widget": {
        // a widget can have a title or color attribute
        "title": { ".validate": true },
        "color": { ".validate": true },

        // but no other child paths are allowed
        // in this case, $other means any key excluding "title" and "color"
        "$other": { ".validate": false }
      }
    }
  }

পদ্ধতি

Realtime Database , তিন ধরনের নিয়ম রয়েছে। এই নিয়মের দুটি ধরন — read এবং write — একটি আগত অনুরোধের পদ্ধতিতে প্রয়োগ করুন৷ validate নিয়মের ধরন ডেটা স্ট্রাকচার প্রয়োগ করে এবং ডেটার বিন্যাস এবং বিষয়বস্তুকে বৈধ করে। .write নিয়ম অ্যাক্সেসের অনুমতি দেয় তা যাচাই করার পরে Rules চলে .validate করে৷

ডিফল্টরূপে, যদি এটির অনুমতি দেওয়ার নিয়ম না থাকে, তবে একটি পাথে অ্যাক্সেস অস্বীকার করা হয়।

Cloud Firestore

একটি শর্ত একটি বুলিয়ান অভিব্যক্তি যা নির্ধারণ করে যে একটি নির্দিষ্ট অপারেশন অনুমোদিত বা অস্বীকার করা উচিত। request এবং resource ভেরিয়েবলগুলি সেই শর্তগুলির জন্য প্রসঙ্গ প্রদান করে।

request পরিবর্তনশীল

request পরিবর্তনশীল নিম্নলিখিত ক্ষেত্র এবং সংশ্লিষ্ট তথ্য অন্তর্ভুক্ত:

request.auth

একটি JSON ওয়েব টোকেন (JWT) যাতে Firebase Authentication থেকে প্রমাণীকরণের প্রমাণপত্র রয়েছে। auth টোকেনে স্ট্যান্ডার্ড দাবির একটি সেট এবং Firebase Authentication মাধ্যমে আপনি যে কোনো কাস্টম দাবি তৈরি করেন। Firebase Security Rules এবং Authentication সম্পর্কে আরও জানুন।

request.method

request.method মানক পদ্ধতি বা একটি কাস্টম পদ্ধতি হতে পারে। read এবং write সুবিধার পদ্ধতিগুলিও লেখার নিয়মগুলিকে সরল করার জন্য বিদ্যমান যা যথাক্রমে সমস্ত পঠন-পাঠন বা সমস্ত লেখার জন্য প্রযোজ্য।

request.params

request.params এমন কোনো ডেটা অন্তর্ভুক্ত থাকে যা বিশেষভাবে request.resource এর সাথে সম্পর্কিত নয় যা মূল্যায়নের জন্য উপযোগী হতে পারে। অনুশীলনে, এই মানচিত্রটি সমস্ত মানক পদ্ধতির জন্য খালি হওয়া উচিত এবং কাস্টম পদ্ধতির জন্য অ-সম্পদ ডেটা থাকা উচিত। পরিষেবাগুলিকে প্যারাম হিসাবে উপস্থাপিত কোনও কী এবং মানগুলির প্রকারের নাম পরিবর্তন বা পরিবর্তন না করার বিষয়ে সতর্ক থাকতে হবে।

request.path

request.path হল টার্গেট resource পথ। পথ সেবার আপেক্ষিক। নন-ইউআরএল নিরাপদ অক্ষর ধারণকারী পাথ সেগমেন্ট যেমন / ইউআরএল-এনকোডেড।

resource পরিবর্তনশীল

resource হল পরিষেবার মধ্যে বর্তমান মান যা কী-মান জোড়ার মানচিত্র হিসাবে উপস্থাপিত হয়। একটি শর্তের মধ্যে resource উল্লেখ করার ফলে পরিষেবা থেকে সর্বাধিক একটি মূল্য পড়া হবে। এই লুকআপটি সম্পদের জন্য যেকোন পরিষেবা-সম্পর্কিত কোটার বিরুদ্ধে গণনা করা হবে। রিকোয়েস্ট get জন্য, resource শুধুমাত্র অস্বীকৃত হলে কোটার দিকে গণনা করা হবে।

অপারেটর এবং অপারেটর অগ্রাধিকার

Cloud Firestore এবং Cloud Storage Rules অপারেটর এবং তাদের সংশ্লিষ্ট অগ্রাধিকারের রেফারেন্স হিসাবে নীচের টেবিলটি ব্যবহার করুন।

প্রদত্ত নির্বিচারে অভিব্যক্তি a এবং b , একটি ক্ষেত্র f , এবং একটি সূচক i .

Cloud Storage

একটি শর্ত একটি বুলিয়ান অভিব্যক্তি যা নির্ধারণ করে যে একটি নির্দিষ্ট অপারেশন অনুমোদিত বা অস্বীকার করা উচিত। request এবং resource ভেরিয়েবলগুলি সেই শর্তগুলির জন্য প্রসঙ্গ প্রদান করে।

request পরিবর্তনশীল

request পরিবর্তনশীল নিম্নলিখিত ক্ষেত্র এবং সংশ্লিষ্ট তথ্য অন্তর্ভুক্ত:

request.auth

একটি JSON ওয়েব টোকেন (JWT) যাতে Firebase Authentication থেকে প্রমাণীকরণের প্রমাণপত্র রয়েছে। auth টোকেনে স্ট্যান্ডার্ড দাবির একটি সেট এবং Firebase Authentication মাধ্যমে আপনি যে কোনো কাস্টম দাবি তৈরি করেন। Firebase Security Rules এবং Authentication সম্পর্কে আরও জানুন।

request.method

request.method মানক পদ্ধতি বা একটি কাস্টম পদ্ধতি হতে পারে। read এবং write সুবিধার পদ্ধতিগুলিও লেখার নিয়মগুলিকে সরল করার জন্য বিদ্যমান যা যথাক্রমে সমস্ত পঠন-পাঠন বা সমস্ত লেখার জন্য প্রযোজ্য।

request.params

request.params এমন কোনো ডেটা অন্তর্ভুক্ত থাকে যা বিশেষভাবে request.resource এর সাথে সম্পর্কিত নয় যা মূল্যায়নের জন্য উপযোগী হতে পারে। অনুশীলনে, এই মানচিত্রটি সমস্ত মানক পদ্ধতির জন্য খালি হওয়া উচিত এবং কাস্টম পদ্ধতির জন্য অ-সম্পদ ডেটা থাকা উচিত। পরিষেবাগুলিকে প্যারাম হিসাবে উপস্থাপিত কোনও কী এবং মানগুলির প্রকারের নাম পরিবর্তন বা পরিবর্তন না করার বিষয়ে সতর্ক থাকতে হবে।

request.path

request.path হল টার্গেট resource পথ। পথ সেবার আপেক্ষিক। নন-ইউআরএল নিরাপদ অক্ষর ধারণকারী পাথ সেগমেন্ট যেমন / ইউআরএল-এনকোডেড।

resource পরিবর্তনশীল

resource হল পরিষেবার মধ্যে বর্তমান মান যা কী-মান জোড়ার মানচিত্র হিসাবে উপস্থাপিত হয়। একটি শর্তের মধ্যে resource উল্লেখ করার ফলে পরিষেবা থেকে সর্বাধিক একটি মূল্য পড়া হবে। এই লুকআপটি সম্পদের জন্য যেকোন পরিষেবা-সম্পর্কিত কোটার বিরুদ্ধে গণনা করা হবে। রিকোয়েস্ট get জন্য, resource শুধুমাত্র অস্বীকৃত হলে কোটার দিকে গণনা করা হবে।

অপারেটর এবং অপারেটর অগ্রাধিকার

Cloud Firestore এবং Cloud Storage Rules অপারেটর এবং তাদের সংশ্লিষ্ট অগ্রাধিকারের রেফারেন্স হিসাবে নীচের টেবিলটি ব্যবহার করুন।

প্রদত্ত নির্বিচারে অভিব্যক্তি a এবং b , একটি ক্ষেত্র f , এবং একটি সূচক i .

Realtime Database

একটি শর্ত একটি বুলিয়ান অভিব্যক্তি যা নির্ধারণ করে যে একটি নির্দিষ্ট অপারেশন অনুমোদিত বা অস্বীকার করা উচিত। আপনি নিম্নলিখিত উপায়ে Realtime Database Rules সেই শর্তগুলি সংজ্ঞায়িত করতে পারেন।

পূর্ব-নির্ধারিত ভেরিয়েবল

অনেকগুলি সহায়ক, পূর্ব-সংজ্ঞায়িত ভেরিয়েবল রয়েছে যা একটি নিয়ম সংজ্ঞার মধ্যে অ্যাক্সেস করা যেতে পারে। এখানে প্রতিটির একটি সংক্ষিপ্ত সারসংক্ষেপ রয়েছে:

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

{
  "rules": {
    "foo": {
      // /foo is readable by the world
      ".read": true,

      // /foo is writable by the world
      ".write": true,

      // data written to /foo must be a string less than 100 characters
      ".validate": "newData.isString() && newData.val().length < 100"
    }
  }
}

ডেটা ভিত্তিক নিয়ম

আপনার ডাটাবেসের যেকোনো ডাটা আপনার নিয়মে ব্যবহার করা যাবে। পূর্বনির্ধারিত ভেরিয়েবল root , data , এবং newData ব্যবহার করে, আপনি যে কোনও পাথ অ্যাক্সেস করতে পারেন কারণ এটি একটি লেখার ইভেন্টের আগে বা পরে থাকবে।

এই উদাহরণটি বিবেচনা করুন, যা /allow_writes/ নোডের মান true হওয়া পর্যন্ত লেখার ক্রিয়াকলাপকে অনুমতি দেয়, প্যারেন্ট নোডের একটি readOnly পতাকা সেট থাকে না এবং নতুন লেখা ডেটাতে foo নামে একটি শিশু রয়েছে:

".write": "root.child('allow_writes').val() === true &&
          !data.parent().child('readOnly').exists() &&
          newData.child('foo').exists()"

প্রশ্ন ভিত্তিক নিয়ম

যদিও আপনি নিয়মগুলিকে ফিল্টার হিসাবে ব্যবহার করতে পারবেন না, আপনি আপনার নিয়মে ক্যোয়ারী প্যারামিটার ব্যবহার করে ডেটার উপসেটগুলিতে অ্যাক্সেস সীমিত করতে পারেন৷ query. ক্যোয়ারী প্যারামিটারের উপর ভিত্তি করে পঠন বা লেখার অ্যাক্সেস মঞ্জুর করতে আপনার নিয়মে অভিব্যক্তি।

উদাহরণ স্বরূপ, নিম্নলিখিত ক্যোয়ারী-ভিত্তিক নিয়ম ব্যবহারকারী-ভিত্তিক নিরাপত্তা নিয়ম এবং ক্যোয়ারী-ভিত্তিক নিয়মগুলি ব্যবহার করে baskets সংগ্রহের ডেটা অ্যাক্সেসকে শুধুমাত্র সক্রিয় ব্যবহারকারীর মালিকানাধীন শপিং বাস্কেটে সীমাবদ্ধ করতে:

"baskets": {
  ".read": "auth.uid !== null &&
            query.orderByChild === 'owner' &&
            query.equalTo === auth.uid" // restrict basket access to owner of basket
}

নিম্নোক্ত ক্যোয়ারী, যার মধ্যে নিয়মের ক্যোয়ারী প্যারামিটার রয়েছে, সফল হবে:

db.ref("baskets").orderByChild("owner")
                 .equalTo(auth.currentUser.uid)
                 .on("value", cb)                 // Would succeed

যাইহোক, নিয়মের প্যারামিটারগুলি অন্তর্ভুক্ত করে না এমন প্রশ্নগুলি PermissionDenied ত্রুটির সাথে ব্যর্থ হবে:

db.ref("baskets").on("value", cb)                 // Would fail with PermissionDenied

পঠিত ক্রিয়াকলাপগুলির মাধ্যমে একজন ক্লায়েন্ট কত ডেটা ডাউনলোড করবে তা সীমাবদ্ধ করতে আপনি ক্যোয়ারী-ভিত্তিক নিয়মগুলিও ব্যবহার করতে পারেন।

উদাহরণ স্বরূপ, নিম্নোক্ত নিয়মটি অগ্রাধিকার দ্বারা আদেশ অনুসারে একটি প্রশ্নের প্রথম 1000টি ফলাফলে পড়ার অ্যাক্সেসকে সীমাবদ্ধ করে:

messages: {
  ".read": "query.orderByKey &&
            query.limitToFirst <= 1000"
}

// Example queries:

db.ref("messages").on("value", cb)                // Would fail with PermissionDenied

db.ref("messages").limitToFirst(1000)
                  .on("value", cb)                // Would succeed (default order by key)

নিম্নলিখিত query. এক্সপ্রেশনগুলি Realtime Database Security Rules উপলব্ধ।

অপারেটর

Realtime Database Rules বেশ কয়েকটি অপারেটরকে সমর্থন করে যা আপনি শর্ত বিবৃতিতে ভেরিয়েবলগুলিকে একত্রিত করতে ব্যবহার করতে পারেন। রেফারেন্স ডকুমেন্টেশনে অপারেটরদের সম্পূর্ণ তালিকা দেখুন।