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

Firebase Security Rules নমনীয়, শক্তিশালী, কাস্টম ভাষা ব্যবহার করে যা বিভিন্ন ধরণের জটিলতা এবং গ্রানুলারিটি সমর্থন করে। আপনি আপনার Rules আপনার অ্যাপের জন্য যতটা সম্ভব নির্দিষ্ট বা সাধারণ করে তুলতে পারেন। Realtime Database রুলস একটি সিনট্যাক্স ব্যবহার করে যা JSON কাঠামোতে জাভাস্ক্রিপ্টের মতো দেখায়। Cloud Firestore এবং Cloud Storage রুলস কমন এক্সপ্রেশন ল্যাঙ্গুয়েজ (CEL) এর উপর ভিত্তি করে একটি ভাষা ব্যবহার করে, যা CEL এর উপর ভিত্তি match তৈরি হয় এবং শর্তসাপেক্ষে অনুমোদিত অ্যাক্সেস সমর্থন করে এমন বিবৃতিগুলিকে allow ।

যেহেতু এগুলো কাস্টম ভাষা, তাই এখানে শেখার একটা ধারা আছে। আরও জটিল নিয়মের গভীরে যাওয়ার সাথে সাথে Rules ভাষা আরও ভালোভাবে বুঝতে এই নির্দেশিকাটি ব্যবহার করুন।

একটি পণ্য নির্বাচন করুন এবং এর নিয়ম সম্পর্কে আরও জানুন।

মৌলিক কাঠামো

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 , এবং 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 , এবং delete । read এবং write সুবিধার্থে পদ্ধতিগুলি নির্দিষ্ট ডাটাবেস বা স্টোরেজ পাথে বিস্তৃত পঠন এবং লেখার অ্যাক্সেস সক্ষম করে।
• পথ: ডাটাবেস বা স্টোরেজ অবস্থান, যা একটি URI পথ হিসাবে উপস্থাপিত হয়।
• নিয়ম: allow স্টেটমেন্ট, যার মধ্যে এমন একটি শর্ত থাকে যা একটি অনুরোধকে সত্য হিসাবে মূল্যায়ন করলে অনুমতি দেয়।

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

Realtime Database

Realtime Database , Firebase Security Rules একটি JSON ডকুমেন্টে থাকা জাভাস্ক্রিপ্টের মতো এক্সপ্রেশন দিয়ে তৈরি।

তারা নিম্নলিখিত বাক্য গঠন ব্যবহার করে:

{
  "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 ঘোষণা: Firebase পণ্যের ক্ষেত্রে প্রযোজ্য নিয়মগুলি ঘোষণা করে।
• match ব্লক: ডাটাবেস বা স্টোরেজ বাকেটের একটি পাথ সংজ্ঞায়িত করে যেখানে নিয়মগুলি প্রযোজ্য।
• allow বিবৃতি: পদ্ধতি অনুসারে অ্যাক্সেস প্রদানের জন্য শর্তাবলী প্রদান করে। সমর্থিত পদ্ধতিগুলির মধ্যে রয়েছে: get , list , create , update , delete , এবং সুবিধাজনক পদ্ধতিগুলি read and write ।
• ঐচ্ছিক function ঘোষণা: একাধিক নিয়ম জুড়ে ব্যবহারের জন্য শর্তগুলিকে একত্রিত এবং মোড়ানোর ক্ষমতা প্রদান করে।

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

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

syntax স্টেটমেন্টটি উৎস লেখার জন্য ব্যবহৃত Firebase Rules ভাষার সংস্করণ নির্দেশ করে। ভাষার সর্বশেষ সংস্করণ হল v2 ।

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

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

সেবা

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

Cloud Firestore

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

Cloud Storage

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

রিকার্সিভ ওয়াইল্ডকার্ড ব্যবহার করা এড়িয়ে চলুন যদি না আপনি অনুমতিমূলক নিরাপত্তা নিয়মগুলি সমস্ত নেস্টেড পাথে প্রচার করার ইচ্ছা করেন।

অনুমতি দিন

match ব্লকে এক বা একাধিক allow স্টেটমেন্ট থাকে। এগুলো আপনার আসল নিয়ম। আপনি এক বা একাধিক পদ্ধতিতে allow রুল প্রয়োগ করতে পারেন। যেকোনো ইনকামিং অনুরোধ মঞ্জুর করার জন্য allow স্টেটমেন্টের শর্তাবলী অবশ্যই Cloud Firestore বা Cloud Storage জন্য সত্য হিসাবে মূল্যায়ন করতে হবে। আপনি শর্ত ছাড়াই 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 স্টেটমেন্টে একটি পদ্ধতি থাকে যা একই পদ্ধতির আগত অনুরোধগুলির জন্য অ্যাক্সেস মঞ্জুর করে।

পদ্ধতি	অনুরোধের ধরণ
সুবিধাজনক পদ্ধতি
read	যেকোনো ধরণের পঠনের অনুরোধ
write	যেকোনো ধরণের লেখার অনুরোধ
স্ট্যান্ডার্ড পদ্ধতি
get	একক নথি বা ফাইলের জন্য অনুরোধগুলি পড়ুন
list	প্রশ্ন এবং সংগ্রহের জন্য অনুরোধগুলি পড়ুন
create	নতুন নথি বা ফাইল লিখুন
update	বিদ্যমান ডাটাবেস নথিতে লিখুন অথবা ফাইল মেটাডেটা আপডেট করুন
delete	ডেটা মুছুন

আপনি একই 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 এর মধ্যে সীমাবদ্ধ।
• rules ভার্সন v2 তে, ফাংশনগুলি let কীওয়ার্ড ব্যবহার করে ভেরিয়েবল সংজ্ঞায়িত করতে পারে। ফাংশনগুলিতে সর্বোচ্চ 10টি let বাইন্ডিং থাকতে পারে, তবে একটি রিটার্ন স্টেটমেন্ট দিয়ে শেষ হতে হবে।

একটি ফাংশন 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();
    }
  }
}

এখানে ফাংশন আর্গুমেন্ট এবং let অ্যাসাইনমেন্ট দেখানোর একটি উদাহরণ দেওয়া হল। Let অ্যাসাইনমেন্ট স্টেটমেন্টগুলিকে সেমিকোলন দ্বারা পৃথক করতে হবে।

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

লক্ষ্য করুন কিভাবে isAdmin অ্যাসাইনমেন্ট অ্যাডমিন সংগ্রহের একটি লুকআপ জোরদার করে। অপ্রয়োজনীয় লুকআপের প্রয়োজন ছাড়াই অলস মূল্যায়নের জন্য, && (AND) এবং || (OR) তুলনার শর্ট-সার্কিটিং প্রকৃতির সুবিধা নিন এবং শুধুমাত্র যদি 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 ঘোষণা: Firebase পণ্যের ক্ষেত্রে প্রযোজ্য নিয়মগুলি ঘোষণা করে।
• match ব্লক: ডাটাবেস বা স্টোরেজ বাকেটের একটি পাথ সংজ্ঞায়িত করে যেখানে নিয়মগুলি প্রযোজ্য।
• allow বিবৃতি: পদ্ধতি অনুসারে অ্যাক্সেস প্রদানের জন্য শর্তাবলী প্রদান করে। সমর্থিত পদ্ধতিগুলির মধ্যে রয়েছে: get , list , create , update , delete , এবং সুবিধাজনক পদ্ধতিগুলি read and write ।
• ঐচ্ছিক function ঘোষণা: একাধিক নিয়ম জুড়ে ব্যবহারের জন্য শর্তগুলিকে একত্রিত এবং মোড়ানোর ক্ষমতা প্রদান করে।

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

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

syntax স্টেটমেন্টটি উৎস লেখার জন্য ব্যবহৃত Firebase Rules ভাষার সংস্করণ নির্দেশ করে। ভাষার সর্বশেষ সংস্করণ হল v2 ।

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

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

সেবা

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

Cloud Firestore

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

Cloud Storage

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

রিকার্সিভ ওয়াইল্ডকার্ড ব্যবহার করা এড়িয়ে চলুন যদি না আপনি অনুমতিমূলক নিরাপত্তা নিয়মগুলি সমস্ত নেস্টেড পাথে প্রচার করার ইচ্ছা করেন।

অনুমতি দিন

match ব্লকে এক বা একাধিক allow স্টেটমেন্ট থাকে। এগুলো আপনার আসল নিয়ম। আপনি এক বা একাধিক পদ্ধতিতে allow রুল প্রয়োগ করতে পারেন। যেকোনো ইনকামিং অনুরোধ মঞ্জুর করার জন্য allow স্টেটমেন্টের শর্তাবলী অবশ্যই Cloud Firestore বা Cloud Storage জন্য সত্য হিসাবে মূল্যায়ন করতে হবে। আপনি শর্ত ছাড়াই 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 স্টেটমেন্টে একটি পদ্ধতি থাকে যা একই পদ্ধতির আগত অনুরোধগুলির জন্য অ্যাক্সেস মঞ্জুর করে।

পদ্ধতি	অনুরোধের ধরণ
সুবিধাজনক পদ্ধতি
read	যেকোনো ধরণের পঠনের অনুরোধ
write	যেকোনো ধরণের লেখার অনুরোধ
স্ট্যান্ডার্ড পদ্ধতি
get	একক নথি বা ফাইলের জন্য অনুরোধগুলি পড়ুন
list	প্রশ্ন এবং সংগ্রহের জন্য অনুরোধগুলি পড়ুন
create	নতুন নথি বা ফাইল লিখুন
update	বিদ্যমান ডাটাবেস নথিতে লিখুন অথবা ফাইল মেটাডেটা আপডেট করুন
delete	ডেটা মুছুন

আপনি একই 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 এর মধ্যে সীমাবদ্ধ।
• rules ভার্সন v2 তে, ফাংশনগুলি let কীওয়ার্ড ব্যবহার করে ভেরিয়েবল সংজ্ঞায়িত করতে পারে। ফাংশনগুলিতে সর্বোচ্চ 10টি let বাইন্ডিং থাকতে পারে, তবে একটি রিটার্ন স্টেটমেন্ট দিয়ে শেষ হতে হবে।

একটি ফাংশন 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();
    }
  }
}

এখানে ফাংশন আর্গুমেন্ট এবং let অ্যাসাইনমেন্ট দেখানোর একটি উদাহরণ দেওয়া হল। Let অ্যাসাইনমেন্ট স্টেটমেন্টগুলিকে সেমিকোলন দ্বারা পৃথক করতে হবে।

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

লক্ষ্য করুন কিভাবে isAdmin অ্যাসাইনমেন্ট অ্যাডমিন সংগ্রহের একটি লুকআপ জোরদার করে। অপ্রয়োজনীয় লুকআপের প্রয়োজন ছাড়াই অলস মূল্যায়নের জন্য, && (AND) এবং || (OR) তুলনার শর্ট-সার্কিটিং প্রকৃতির সুবিধা নিন এবং শুধুমাত্র যদি 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 লেখার নিয়মগুলিকে সরল করার জন্যও বিদ্যমান যা যথাক্রমে সমস্ত read-only বা সমস্ত write-only স্ট্যান্ডার্ড পদ্ধতিতে প্রযোজ্য।

request.params

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

request.path

request.path হল টার্গেট resource পাথ। পাথটি পরিষেবার সাথে সম্পর্কিত। যেসব পাথ সেগমেন্টে / মতো নন-url নিরাপদ অক্ষর থাকে, সেগুলো url-এনকোডেড।

resource ভেরিয়েবল

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

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

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

a এবং b , একটি ক্ষেত্র f এবং একটি সূচক i এই বিষয়ে বিষয়গুলো বিবেচনা করলেই হবে।

অপারেটর	বিবরণ	সহযোগীতা
a[i] a() af	সূচক, কল, ক্ষেত্র অ্যাক্সেস	বাম থেকে ডানে
!a -a	একমুখী নেতিবাচকতা	ডান থেকে বামে
a/ba%ba*b	গুণক অপারেটর	বাম থেকে ডানে
a+b ab	সংযোজক অপারেটর	বাম থেকে ডানে
a>ba>=ba	রিলেশনাল অপারেটর	বাম থেকে ডানে
a in b	তালিকা বা মানচিত্রে অস্তিত্ব	বাম থেকে ডানে
a is type	টাইপ তুলনা, যেখানে type bool, int, float, number, string, list, map, timestamp, duration, path অথবা latlng হতে পারে।	বাম থেকে ডানে
a==ba!=b	তুলনা অপারেটর	বাম থেকে ডানে
a && b	শর্তসাপেক্ষ এবং	বাম থেকে ডানে
a || b	শর্তসাপেক্ষ OR	বাম থেকে ডানে
a ? true_value : false_value	টারনারি এক্সপ্রেশন	বাম থেকে ডানে

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 লেখার নিয়মগুলিকে সরল করার জন্যও বিদ্যমান যা যথাক্রমে সমস্ত read-only বা সমস্ত write-only স্ট্যান্ডার্ড পদ্ধতিতে প্রযোজ্য।

request.params

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

request.path

request.path হল টার্গেট resource পাথ। পাথটি পরিষেবার সাথে সম্পর্কিত। যেসব পাথ সেগমেন্টে / মতো নন-url নিরাপদ অক্ষর থাকে, সেগুলো url-এনকোডেড।

resource ভেরিয়েবল

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

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

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

a এবং b , একটি ক্ষেত্র f এবং একটি সূচক i এই বিষয়ে বিষয়গুলো বিবেচনা করলেই হবে।

অপারেটর	বিবরণ	সহযোগীতা
a[i] a() af	সূচক, কল, ক্ষেত্র অ্যাক্সেস	বাম থেকে ডানে
!a -a	একমুখী নেতিবাচকতা	ডান থেকে বামে
a/ba%ba*b	গুণক অপারেটর	বাম থেকে ডানে
a+b ab	সংযোজক অপারেটর	বাম থেকে ডানে
a>ba>=ba	রিলেশনাল অপারেটর	বাম থেকে ডানে
a in b	তালিকা বা মানচিত্রে অস্তিত্ব	বাম থেকে ডানে
a is type	টাইপ তুলনা, যেখানে type bool, int, float, number, string, list, map, timestamp, duration, path অথবা latlng হতে পারে।	বাম থেকে ডানে
a==ba!=b	তুলনা অপারেটর	বাম থেকে ডানে
a && b	শর্তসাপেক্ষ এবং	বাম থেকে ডানে
a || b	শর্তসাপেক্ষ OR	বাম থেকে ডানে
a ? true_value : false_value	টারনারি এক্সপ্রেশন	বাম থেকে ডানে

Realtime Database

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

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

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

পূর্বনির্ধারিত ভেরিয়েবল
এখন	লিনাক্স যুগের পর থেকে মিলিসেকেন্ডে বর্তমান সময়। এটি SDK এর firebase.database.ServerValue.TIMESTAMP দিয়ে তৈরি টাইমস্ট্যাম্প যাচাই করার জন্য বিশেষভাবে ভালো কাজ করে।
মূল	একটি RuleDataSnapshot যা Firebase ডাটাবেসের রুট পাথকে উপস্থাপন করে যেমনটি অপারেশনের চেষ্টা করার আগে বিদ্যমান ছিল।
নতুন তথ্য	একটি RuleDataSnapshot যা অপারেশনের চেষ্টার পরে ডেটা যেমন বিদ্যমান থাকবে তেমনভাবে উপস্থাপন করে। এতে নতুন ডেটা লেখা হচ্ছে এবং বিদ্যমান ডেটা অন্তর্ভুক্ত রয়েছে।
তথ্য	একটি RuleDataSnapshot যা অপারেশনের আগে বিদ্যমান ডেটার প্রতিনিধিত্ব করে।
$ ভেরিয়েবল	আইডি এবং ডাইনামিক চাইল্ড কী উপস্থাপন করতে ব্যবহৃত একটি ওয়াইল্ডকার্ড পাথ।
প্রমাণীকরণ	একটি প্রমাণিত ব্যবহারকারীর টোকেন পেলোড প্রতিনিধিত্ব করে।

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

{
  "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

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

উদাহরণস্বরূপ, নিম্নলিখিত নিয়মটি অগ্রাধিকার অনুসারে, কোনও প্রশ্নের প্রথম ১০০০টি ফলাফলের পঠন অ্যাক্সেস সীমিত করে:

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 -এ উপলব্ধ।

কোয়েরি-ভিত্তিক নিয়মের এক্সপ্রেশন
অভিব্যক্তি	আদর্শ	বিবরণ
query.orderByKey সম্পর্কে query.orderByPriority সম্পর্কে query.orderByValue সম্পর্কে	বুলিয়ান	কী, অগ্রাধিকার, অথবা মান অনুসারে সাজানো প্রশ্নের ক্ষেত্রে সত্য। অন্যথায় মিথ্যা।
query.orderByChild সম্পর্কে	স্ট্রিং শূন্য	একটি চাইল্ড নোডের আপেক্ষিক পথ উপস্থাপন করতে একটি স্ট্রিং ব্যবহার করুন। উদাহরণস্বরূপ, query.orderByChild === "address/zip" । যদি কোয়েরিটি একটি চাইল্ড নোড দ্বারা ক্রমানুসারে না থাকে, তাহলে এই মানটি null হবে।
query.startAt সম্পর্কে query.endAt সম্পর্কে query.equalTo সম্পর্কে	স্ট্রিং সংখ্যা বুলিয়ান শূন্য	এক্সিকিউটিং কোয়েরির সীমানা পুনরুদ্ধার করে, অথবা যদি কোনও সীমানা সেট না থাকে তবে null ফেরত দেয়।
query.limitToFirst সম্পর্কে query.limitToLast সম্পর্কে	সংখ্যা শূন্য	এক্সিকিউটিং কোয়েরির সীমা পুনরুদ্ধার করে, অথবা যদি কোনও সীমা সেট না থাকে তবে null ফেরত দেয়।

অপারেটর

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

পরিস্থিতি তৈরি করা

আপনার প্রকৃত শর্তাবলী আপনি যে অ্যাক্সেস দিতে চান তার উপর নির্ভর করে পরিবর্তিত হবে। Rules ইচ্ছাকৃতভাবে প্রচুর পরিমাণে নমনীয়তা প্রদান করে, তাই আপনার অ্যাপের নিয়মগুলি শেষ পর্যন্ত আপনার প্রয়োজন অনুসারে সহজ বা জটিল হতে পারে।

সহজ, উৎপাদন-প্রস্তুত Rules তৈরির কিছু নির্দেশনার জন্য, মৌলিক নিরাপত্তা নিয়ম দেখুন।