Save the date for Firebase Demo Day 2024. Learn how to build and run modern, AI-powered apps users love. Learn more.

এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

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

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

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 ব্লক থাকতে হবে, বিবৃতি বা 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 বিবৃতিতে একটি পদ্ধতি রয়েছে যা একই পদ্ধতির আগত অনুরোধগুলির জন্য অ্যাক্সেস মঞ্জুর করে।

পদ্ধতি	অনুরোধের ধরন
সুবিধার পদ্ধতি
`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-এর মধ্যে সীমাবদ্ধ।
নিয়ম সংস্করণ 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 ঘোষণা: একাধিক নিয়ম জুড়ে ব্যবহারের জন্য শর্ত একত্রিত এবং মোড়ানোর ক্ষমতা প্রদান করুন।

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

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

সেবা

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
}

ম্যাচ

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

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

// 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 স্টেটমেন্টের মধ্যে অ্যাক্সেসযোগ্য।

অনুমতি দিন

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

পদ্ধতি

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

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

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 পর্যন্ত লেট বাইন্ডিং থাকতে পারে, কিন্তু একটি রিটার্ন স্টেটমেন্ট দিয়ে শেষ করতে হবে।

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

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 .

অপারেটর	বর্ণনা	সহযোগীতা
`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, সংখ্যা, স্ট্রিং, তালিকা, মানচিত্র, টাইমস্ট্যাম্প, সময়কাল, পথ বা ল্যাটলং	বাম থেকে ডান
`a==ba!=b`	তুলনা অপারেটর	বাম থেকে ডান
`a && b`	শর্তাধীন এবং	বাম থেকে ডান
`a \|\| b`	শর্তাধীন বা	বাম থেকে ডান
`a ? true_value : false_value`	টার্নারি এক্সপ্রেশন	বাম থেকে ডান

Cloud Storage

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

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

`request.auth`

`request.method`

`request.params`

`request.path`

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

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

প্রদত্ত নির্বিচারে অভিব্যক্তি 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, সংখ্যা, স্ট্রিং, তালিকা, মানচিত্র, টাইমস্ট্যাম্প, সময়কাল, পথ বা ল্যাটলং	বাম থেকে ডান
`a==ba!=b`	তুলনা অপারেটর	বাম থেকে ডান
`a && b`	শর্তাধীন এবং	বাম থেকে ডান
`a \|\| b`	শর্তাধীন বা	বাম থেকে ডান
`a ? true_value : false_value`	টার্নারি এক্সপ্রেশন	বাম থেকে ডান

Realtime Database

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

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

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

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

এই ভেরিয়েবলগুলি আপনার নিয়মের যেকোনো জায়গায় ব্যবহার করা যেতে পারে। উদাহরণস্বরূপ, নীচের নিরাপত্তা নিয়মগুলি নিশ্চিত করে যে /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 উপলব্ধ।

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

অপারেটর

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

শর্ত তৈরি করা

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

সহজ, উৎপাদন-প্রস্তুত 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 , 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 ঘোষণা: একাধিক নিয়ম জুড়ে ব্যবহারের জন্য শর্ত একত্রিত এবং মোড়ানোর ক্ষমতা প্রদান করুন।

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

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

সেবা

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
}

ম্যাচ

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

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

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

// 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 অ্যাক্সেসকে মঞ্জুর করে এবং আরও কোনও দানাদার বিধি উপেক্ষা করে যা অ্যাক্সেসকে সীমাবদ্ধ করতে পারে।

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

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 মধ্যে সংজ্ঞায়িত একটি ফাংশন 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 অ্যাসাইনমেন্ট কীভাবে প্রশাসনিক সংগ্রহের সন্ধানকে কার্যকর করে তা নোট করুন। অলস মূল্যায়নের জন্য অপ্রয়োজনীয় অনুসন্ধানের প্রয়োজন ছাড়াই, && (এবং) এর স্বল্প-উত্সাহী প্রকৃতির সুবিধা নিন এবং || (বা) দ্বিতীয় ফাংশন কল করার জন্য তুলনাগুলি কেবল তখনই যদি 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 ।
Al চ্ছিক function ঘোষণা: একাধিক বিধি জুড়ে ব্যবহারের জন্য শর্তাদি একত্রিত এবং মোড়ানোর ক্ষমতা সরবরাহ করুন।

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

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

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

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

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

সেবা

service ঘোষণাপত্রটি কোন ফায়ারবেস পণ্য বা পরিষেবা, আপনার নিয়মগুলি প্রযোজ্য তা নির্ধারণ করে। আপনি কেবল উত্স ফাইল প্রতি একটি 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 সিএলআই ব্যবহার করে 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 প্রয়োগ করতে পারেন। কোনও আগত অনুরোধ মঞ্জুর করার জন্য কোনও allow বিবৃতিতে শর্তগুলি Cloud Firestore বা Cloud Storage জন্য সত্যকে মূল্যায়ন করতে হবে। আপনি শর্ত ছাড়াই বিবৃতি allow লিখতে পারেন, উদাহরণস্বরূপ, allow read । যদি allow বিবৃতিতে কোনও শর্ত অন্তর্ভুক্ত না হয় তবে এটি সর্বদা সেই পদ্ধতির জন্য অনুরোধের অনুমতি দেয়।

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

পদ্ধতি

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

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

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 মধ্যে সংজ্ঞায়িত একটি ফাংশন Firestore স্কোপটিতে resource ভেরিয়েবল এবং অন্তর্নির্মিত ফাংশন যেমন get() এবং exists() এর অ্যাক্সেস রয়েছে।
ফাংশনগুলি অন্যান্য ফাংশনগুলিতে কল করতে পারে তবে পুনরাবৃত্তি হতে পারে না। মোট কল স্ট্যাক গভীরতা 20 এর মধ্যে সীমাবদ্ধ।
বিধি সংস্করণ v2 -তে, ফাংশনগুলি let কীওয়ার্ডটি ব্যবহার করে ভেরিয়েবলগুলি সংজ্ঞায়িত করতে পারে। ফাংশনগুলিতে 10 টি পর্যন্ত বাইন্ডিং থাকতে পারে তবে অবশ্যই একটি রিটার্ন স্টেটমেন্ট দিয়ে শেষ করতে হবে।

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

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 মধ্যে তিনটি প্রাথমিক উপাদান অন্তর্ভুক্ত রয়েছে: ডাটাবেসের জেএসএন কাঠামোর আয়না হিসাবে ডাটাবেসের অবস্থান, অনুরোধের ধরণ এবং শর্তটি অ্যাক্সেস মঞ্জুর করে।

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

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

  {
    "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 ভেরিয়েবলকে সমর্থন করে। আপনার $ সামনের অংশটি আপনার নিয়মের সাথে পথের সাথে যে কোনও শিশু নোডের সাথে মেলে use

  {
    "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 নিয়মের ধরণ ডেটা কাঠামো প্রয়োগ করে এবং ডেটা ফর্ম্যাট এবং সামগ্রীকে বৈধ করে। Rules .write হয় .validate

নিয়মের ধরন
পড়ুন	ব্যবহারকারীদের দ্বারা ডেটা পড়ার অনুমতি দেওয়া হয় কিনা তা বর্ণনা করে।
.লিখুন	কখন ডেটা লেখার অনুমতি দেওয়া হয় তা বর্ণনা করে।
.ভ্যালিডেট	সঠিকভাবে ফর্ম্যাট করা মানটি দেখতে কেমন হবে তা সংজ্ঞায়িত করে, এতে সন্তানের বৈশিষ্ট্য রয়েছে এবং ডেটা টাইপ রয়েছে কিনা।

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

বিল্ডিং শর্ত

Cloud Firestore

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

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

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

`request.auth`

একটি জেএসএন ওয়েব টোকেন (জেডাব্লুটি) যা 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 ।

অপারেটর	বর্ণনা	সহযোগীতা
`a[i] a() af`	সূচক, কল, ক্ষেত্র অ্যাক্সেস	বাম থেকে ডান
`!a -a`	ইউনারি নেগেটিভ	ডান থেকে বাম
`a/ba%ba*b`	গুণক অপারেটর	বাম থেকে ডান
`a+b ab`	অ্যাডিটিভ অপারেটর	বাম থেকে ডান
`a>ba>=ba`	রিলেশনাল অপারেটর	বাম থেকে ডান
`a in b`	তালিকা বা মানচিত্রে অস্তিত্ব	বাম থেকে ডান
`a is type`	টাইপ তুলনা, যেখানে `type` বুল, ইনট, ফ্লোট, সংখ্যা, স্ট্রিং, তালিকা, মানচিত্র, টাইমস্ট্যাম্প, সময়কাল, পথ বা ল্যাটলং হতে পারে	বাম থেকে ডান
`a==ba!=b`	তুলনা অপারেটর	বাম থেকে ডান
`a && b`	শর্তসাপেক্ষ এবং	বাম থেকে ডান
`a \|\| b`	শর্তসাপেক্ষ বা	বাম থেকে ডান
`a ? true_value : false_value`	টেরিনারি এক্সপ্রেশন	বাম থেকে ডান

Cloud Storage

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

`request.auth`

`request.method`

`request.params`

`request.path`

`resource` ভেরিয়েবল

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

নির্বিচারে অভিব্যক্তি 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` বুল, ইনট, ফ্লোট, সংখ্যা, স্ট্রিং, তালিকা, মানচিত্র, টাইমস্ট্যাম্প, সময়কাল, পথ বা ল্যাটলং হতে পারে	বাম থেকে ডান
`a==ba!=b`	তুলনা অপারেটর	বাম থেকে ডান
`a && b`	শর্তসাপেক্ষ এবং	বাম থেকে ডান
`a \|\| b`	শর্তসাপেক্ষ বা	বাম থেকে ডান
`a ? true_value : false_value`	টেরিনারি এক্সপ্রেশন	বাম থেকে ডান

Realtime Database

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

প্রাক-সংজ্ঞায়িত ভেরিয়েবল

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

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

এই ভেরিয়েবলগুলি আপনার নিয়মের যে কোনও জায়গায় ব্যবহার করা যেতে পারে। উদাহরণস্বরূপ, নীচের সুরক্ষা বিধিগুলি নিশ্চিত করে যে /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 এক্সপ্রেশনগুলি উপলব্ধ।

ক্যোয়ারী-ভিত্তিক নিয়ম অভিব্যক্তি
অভিব্যক্তি	টাইপ	বর্ণনা
queery.orderbykey Query.orderbypriority Query.orderbyvalue	বুলিয়ান	কী, অগ্রাধিকার বা মান দ্বারা অর্ডার করা প্রশ্নের জন্য সত্য। অন্যথায় মিথ্যা।
Query.orderbychild	স্ট্রিং নাল	একটি শিশু নোডের আপেক্ষিক পথ উপস্থাপন করতে একটি স্ট্রিং ব্যবহার করুন। উদাহরণস্বরূপ, `query.orderByChild === "address/zip"` । যদি কোয়েরি কোনও শিশু নোড দ্বারা অর্ডার না করা হয় তবে এই মানটি বাতিল।
ক্যোয়ারী.স্টার্ট্যাট quey.endat ক্যোয়ারী.ইকোল্টো	স্ট্রিং সংখ্যা বুলিয়ান নাল	এক্সিকিউটিং ক্যোয়ারির সীমাটি পুনরুদ্ধার করে, বা কোনও আবদ্ধ সেট না থাকলে নালটি ফেরত দেয়।
quey.limittofirst ক্যোয়ারী.লিমিটলাস্ট	সংখ্যা নাল	এক্সিকিউ্টিং ক্যোয়ারির সীমাটি পুনরুদ্ধার করে, বা কোনও সীমা সেট না থাকলে নালটি ফেরত দেয়।

অপারেটর

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

শর্ত তৈরি করা

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

কিছু দিকনির্দেশের জন্য সহজ, উত্পাদন-প্রস্তুত Rules তৈরি করার জন্য, প্রাথমিক সুরক্ষা বিধিগুলি দেখুন।

Firebase Security Rules নমনীয়, শক্তিশালী, কাস্টম ভাষাগুলি লাভ করে যা বিস্তৃত জটিলতা এবং গ্রানুলারিটি সমর্থন করে। আপনি আপনার Rules নির্দিষ্ট বা সাধারণ হিসাবে আপনার অ্যাপ্লিকেশনটির জন্য বোধগম্য হিসাবে তৈরি করতে পারেন। Realtime Database বিধিগুলি একটি সিনট্যাক্স ব্যবহার করে যা কোনও জেএসএন কাঠামোর জাভাস্ক্রিপ্টের মতো দেখায়। Cloud Firestore এবং Cloud Storage বিধিগুলি সাধারণ এক্সপ্রেশন ল্যাঙ্গুয়েজ (সিএল) এর উপর ভিত্তি করে একটি ভাষা ব্যবহার করে, যা 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 সুবিধার্থে পদ্ধতিগুলি নির্দিষ্ট ডাটাবেস বা স্টোরেজ পাথটিতে বিস্তৃত পঠন এবং লেখার অ্যাক্সেস সক্ষম করে।
পাথ: ডাটাবেস বা স্টোরেজ অবস্থান, একটি ইউআরআই পাথ হিসাবে প্রতিনিধিত্ব করে।
বিধি: 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 সুবিধার্থে পদ্ধতিগুলি নির্দিষ্ট ডাটাবেস বা স্টোরেজ পাথটিতে বিস্তৃত পঠন এবং লেখার অ্যাক্সেস সক্ষম করে।
পাথ: ডাটাবেস বা স্টোরেজ অবস্থান, একটি ইউআরআই পাথ হিসাবে প্রতিনিধিত্ব করে।
বিধি: allow বিবৃতি, যার মধ্যে এমন একটি শর্ত অন্তর্ভুক্ত রয়েছে যা যদি কোনও অনুরোধকে সত্যের মূল্যায়ন করে তবে অনুমতি দেয়।

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

Realtime Database

Realtime Database , Firebase Security Rules একটি জেএসএন ডকুমেন্টে থাকা জাভাস্ক্রিপ্ট-জাতীয় অভিব্যক্তি নিয়ে গঠিত।

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

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

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

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

নিয়ম নির্মাণ

Cloud Firestore

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

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

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

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

সেবা

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
}

ম্যাচ

কোনও path প্যাটার্নের বিরুদ্ধে ম্যাচগুলি আংশিক বা সম্পূর্ণ হতে পারে:

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

// 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.
  }
}

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

অনুমতি দিন

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

পদ্ধতি

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

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

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 মধ্যে সংজ্ঞায়িত একটি ফাংশন Firestore স্কোপটিতে resource ভেরিয়েবল এবং অন্তর্নির্মিত ফাংশন যেমন get() এবং exists() এর অ্যাক্সেস রয়েছে।
ফাংশনগুলি অন্যান্য ফাংশনগুলিতে কল করতে পারে তবে পুনরাবৃত্তি হতে পারে না। মোট কল স্ট্যাক গভীরতা 20 এর মধ্যে সীমাবদ্ধ।
বিধি সংস্করণ v2 -তে, ফাংশনগুলি let কীওয়ার্ডটি ব্যবহার করে ভেরিয়েবলগুলি সংজ্ঞায়িত করতে পারে। ফাংশনগুলিতে 10 টি পর্যন্ত বাইন্ডিং থাকতে পারে তবে অবশ্যই একটি রিটার্ন স্টেটমেন্ট দিয়ে শেষ করতে হবে।

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

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 ।
Al চ্ছিক function ঘোষণা: একাধিক বিধি জুড়ে ব্যবহারের জন্য শর্তাদি একত্রিত এবং মোড়ানোর ক্ষমতা সরবরাহ করুন।

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

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

সেবা

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
}

ম্যাচ

কোনও path প্যাটার্নের বিরুদ্ধে ম্যাচগুলি আংশিক বা সম্পূর্ণ হতে পারে:

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

// 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.
  }
}

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

অনুমতি দিন

match ব্লকে এক বা একাধিক বিবৃতি allow । এগুলি আপনার আসল নিয়ম। আপনি এক বা একাধিক পদ্ধতিতে বিধি allow প্রয়োগ করতে পারেন। The conditions on an allow statement must evaluate to true for Cloud Firestore or Cloud Storage to grant any incoming request. You can also write allow statements without conditions, for example, allow read . If the allow statement doesn't include a condition, however, it always allows the request for that method.

If any of the allow rules for the method are satisfied, the request is allowed. Additionally, if a broader rule grants access, Rules grant access and ignore any more granular rules that might limit access.

Consider the following example, where any user can read or delete any of their own files. A more granular rule only allows writes if the user requesting the write owns the file and the file is a PNG. A user can delete any files at the subpath — even if they're not PNGs — because the earlier rule allows it.

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

পদ্ধতি

Each allow statement includes a method that grants access for incoming requests of the same method.

পদ্ধতি	অনুরোধের ধরন
সুবিধার পদ্ধতি
`read`	Any type of read request
`write`	Any type of write request
স্ট্যান্ডার্ড পদ্ধতি
`get`	Read requests for single documents or files
`list`	Read requests for queries and collections
`create`	Write new documents or files
`update`	Write to existing database documents or update file metadata
`delete`	ডেটা মুছুন

You can't overlap read methods in the same match block or conflicting write methods in the same path declaration.

For example, the following rules would fail:

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

ফাংশন

As your security rules become more complex, you may want to wrap sets of conditions in functions that you can reuse across your ruleset. Security rules support custom functions. The syntax for custom functions is a bit like JavaScript, but security rules functions are written in a domain-specific language that has some important limitations:

Functions can contain only a single return statement. They cannot contain any additional logic. For example, they cannot execute loops or call external services.
Functions can automatically access functions and variables from the scope in which they are defined. For example, a function defined within the service cloud.firestore scope has access to the resource variable and built-in functions such as get() and exists() .
Functions may call other functions but may not recurse. The total call stack depth is limited to 20.
In rules version v2 , functions can define variables using the let keyword. Functions can have up to 10 let bindings, but must end with a return statement.

A function is defined with the function keyword and takes zero or more arguments. For example, you may want to combine the two types of conditions used in the examples above into a single 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();
    }
  }
}

Here is an example showing function arguments and let assignments. Let assignment statements must be separated by semi-colons.

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

Note how the isAdmin assignment enforces a lookup of the admins collection. For lazy evaluation without requiring unneeded lookups, take advantage of the short-circuiting nature of && (AND) and || (OR) comparisons to call a second function only if isAuthor is shown to be true (for && comparisons) or false (for || comparisons).

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

Using functions in your security rules makes them more maintainable as the complexity of your rules grows.

Realtime Database

As outlined above, Realtime Database Rules include three basic elements: the database location as a mirror of the database's JSON structure, the request type, and the condition granting access.

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

The structure of your rules should follow the structure of the data you have stored in your database. For example, in a chat app with a list of messages, you might have data that looks like this:

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

Your rules should mirror that structure. যেমন:

  {
    "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()"
        }
      }
    }
  }

As the example above shows, Realtime Database Rules support a $location variable to match path segments. Use the $ prefix in front of your path segment to match your rule to any child nodes along the path.

  {
    "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')"
          }
        }
      }
    }
  }

You can also use the $variable in parallel with constant path names.

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

পদ্ধতি

In Realtime Database , there are three types of rules. Two of these rule types — read and write — apply to the method of an incoming request. The validate rule type enforces data structures and validates the format and content of data. Rules run .validate rules after verifying that a .write rule grants access.

নিয়মের ধরন
.read	Describes if and when data is allowed to be read by users.
.লিখুন	Describes if and when data is allowed to be written.
.validate	Defines what a correctly formatted value will look like, whether it has child attributes, and the data type.

By default, if there isn't a rule allowing it, access at a path is denied.

Building conditions

Cloud Firestore

A condition is a boolean expression that determines whether a particular operation should be allowed or denied. The request and resource variables provide context for those conditions.

The `request` variable

The request variable includes the following fields and corresponding information:

`request.auth`

A JSON Web Token (JWT) that contains authentication credentials from Firebase Authentication . auth token contains a set of standard claims and any custom claims you create through Firebase Authentication . Learn more about Firebase Security Rules and Authentication .

`request.method`

The request.method may be any of the standard methods or a custom method. The convenience methods read and write also exist to simplify writing rules that apply to all read-only or all write-only standard methods respectively.

`request.params`

The request.params include any data not specifically related to the request.resource that might be useful for evaluation. In practice, this map should be empty for all standard methods, and should contain non-resource data for custom methods. Services must be careful not to rename or modify the type of any of the keys and values presented as params.

`request.path`

The request.path is the path for the target resource . The path is relative to the service. Path segments containing non-url safe characters such as / are url-encoded.

The `resource` variable

The resource is the current value within the service represented as a map of key-value pairs. Referencing resource within a condition will result in at most one read of the value from the service. This lookup will count against any service-related quota for the resource. For get requests, the resource will only count toward quota on deny.

Operators and operator precedence

Use the table below as a reference for operators and their corresponding precedence in Rules for Cloud Firestore and Cloud Storage .

Given arbitrary expressions a and b , a field f , and an index i .

অপারেটর	বর্ণনা	সহযোগীতা
`a[i] a() af`	Index, call, field access	বাম থেকে ডান
`!a -a`	ইউনারি নেগেটিভ	right to left
`a/ba%ba*b`	Multiplicative operators	বাম থেকে ডান
`a+b ab`	Additive operators	বাম থেকে ডান
`a>ba>=ba`	রিলেশনাল অপারেটর	বাম থেকে ডান
`a in b`	Existence in list or map	বাম থেকে ডান
`a is type`	Type comparison, where `type` can be bool, int, float, number, string, list, map, timestamp, duration, path or latlng	বাম থেকে ডান
`a==ba!=b`	তুলনা অপারেটর	বাম থেকে ডান
`a && b`	Conditional AND	বাম থেকে ডান
`a \|\| b`	Conditional OR	বাম থেকে ডান
`a ? true_value : false_value`	Ternary expression	বাম থেকে ডান

Cloud Storage

A condition is a boolean expression that determines whether a particular operation should be allowed or denied. The request and resource variables provide context for those conditions.

The `request` variable

The request variable includes the following fields and corresponding information:

`request.auth`

`request.method`

`request.params`

`request.path`

The request.path is the path for the target resource . The path is relative to the service. Path segments containing non-url safe characters such as / are url-encoded.

The `resource` variable

Operators and operator precedence

Use the table below as a reference for operators and their corresponding precedence in Rules for Cloud Firestore and Cloud Storage .

Given arbitrary expressions a and b , a field f , and an index i .

অপারেটর	বর্ণনা	সহযোগীতা
`a[i] a() af`	Index, call, field access	বাম থেকে ডান
`!a -a`	ইউনারি নেগেটিভ	right to left
`a/ba%ba*b`	Multiplicative operators	বাম থেকে ডান
`a+b ab`	Additive operators	বাম থেকে ডান
`a>ba>=ba`	রিলেশনাল অপারেটর	বাম থেকে ডান
`a in b`	Existence in list or map	বাম থেকে ডান
`a is type`	Type comparison, where `type` can be bool, int, float, number, string, list, map, timestamp, duration, path or latlng	বাম থেকে ডান
`a==ba!=b`	তুলনা অপারেটর	বাম থেকে ডান
`a && b`	Conditional AND	বাম থেকে ডান
`a \|\| b`	Conditional OR	বাম থেকে ডান
`a ? true_value : false_value`	Ternary expression	বাম থেকে ডান

Realtime Database

A condition is a boolean expression that determines whether a particular operation should be allowed or denied. You can define those conditions in Realtime Database Rules in the following ways.

Pre-defined variables

There are a number of helpful, pre-defined variables that can be accessed inside a rule definition. এখানে প্রতিটির একটি সংক্ষিপ্ত সারসংক্ষেপ রয়েছে:

পূর্বনির্ধারিত ভেরিয়েবল
এখন	The current time in milliseconds since Linux epoch. This works particularly well for validating timestamps created with the SDK's firebase.database.ServerValue.TIMESTAMP.
মূল	A RuleDataSnapshot representing the root path in the Firebase database as it exists before the attempted operation.
নতুন ডেটা	A RuleDataSnapshot representing the data as it would exist after the attempted operation. It includes the new data being written and existing data.
তথ্য	A RuleDataSnapshot representing the data as it existed before the attempted operation.
$ variables	A wildcard path used to represent ids and dynamic child keys.
প্রমাণ	Represents an authenticated user's token payload.

These variables can be used anywhere in your rules. For example, the security rules below ensure that data written to the /foo/ node must be a string less than 100 characters:

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

Data-based rules

Any data in your database can be used in your rules. Using the predefined variables root , data , and newData , you can access any path as it would exist before or after a write event.

Consider this example, which allows write operations as long as the value of the /allow_writes/ node is true , the parent node does not have a readOnly flag set, and there is a child named foo in the newly written data:

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

Query-based rules

Although you can't use rules as filters, you can limit access to subsets of data by using query parameters in your rules. Use query. expressions in your rules to grant read or write access based on query parameters.

For example, the following query-based rule uses user-based security rules and query-based rules to restrict access to data in the baskets collection to only the shopping baskets the active user owns:

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

The following query, which includes the query parameters in the rule, would succeed:

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

However, queries that do not include the parameters in the rule would fail with a PermissionDenied error:

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

You can also use query-based rules to limit how much data a client downloads through read operations.

For example, the following rule limits read access to only the first 1000 results of a query, as ordered by priority:

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)

The following query. expressions are available in Realtime Database Security Rules .

Query-based rule expressions
অভিব্যক্তি	টাইপ	বর্ণনা
query.orderByKey query.orderByPriority query.orderByValue	বুলিয়ান	True for queries ordered by key, priority, or value. False otherwise.
query.orderByChild	স্ট্রিং নাল	Use a string to represent the relative path to a child node. For example, `query.orderByChild === "address/zip"` . If the query isn't ordered by a child node, this value is null.
query.startAt query.endAt query.equalTo	স্ট্রিং সংখ্যা বুলিয়ান নাল	Retrieves the bounds of the executing query, or returns null if there is no bound set.
query.limitToFirst query.limitToLast	সংখ্যা নাল	Retrieves the limit on the executing query, or returns null if there is no limit set.

অপারেটর

Realtime Database Rules support a number of operators you can use to combine variables in the condition statement. See the full list of operators in the reference documentation .

Creating conditions

Your actual conditions will vary based on the access you want to grant. Rules intentionally offer an enormous degree of flexibility, so your app's rules can ultimately be as simple or as complex as you need them to be.

For some guidance creating simple, production-ready Rules , see Basic Security Rules .

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

মৌলিক কাঠামো

Cloud Firestore

Cloud Storage

Realtime Database

নিয়ম গঠন করে

Cloud Firestore

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

সেবা

Cloud Firestore

Cloud Storage

ম্যাচ

অনুমতি দিন

পদ্ধতি

ফাংশন

Cloud Storage

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

সেবা

Cloud Firestore

Cloud Storage

ম্যাচ

অনুমতি দিন

পদ্ধতি

ফাংশন

Realtime Database

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

পদ্ধতি

বিল্ডিং শর্ত

Cloud Firestore

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

request.auth

request.method

request.params

request.path

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

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

Cloud Storage

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

request.auth

request.method

request.params

request.path

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

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

Realtime Database

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

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

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

অপারেটর

শর্ত তৈরি করা

মৌলিক কাঠামো

Cloud Firestore

Cloud Storage

Realtime Database

নিয়ম গঠন করে

Cloud Firestore

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

সেবা

Cloud Firestore

Cloud Storage

ম্যাচ

অনুমতি দিন

পদ্ধতি

ফাংশন

Cloud Storage

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

সেবা

Cloud Firestore

Cloud Storage

ম্যাচ

অনুমতি দিন

পদ্ধতি

ফাংশন

Realtime Database

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

পদ্ধতি

বিল্ডিং শর্ত

Cloud Firestore

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

request.auth

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

`request.auth`

`request.method`

`request.params`

`request.path`

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

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

`request.auth`

`request.method`

`request.params`

`request.path`

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

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

`request.auth`

`request.method`

`request.params`

`request.path`

`resource` ভেরিয়েবল

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

`request.auth`

`request.method`

`request.params`

`request.path`

`resource` ভেরিয়েবল

The `request` variable

`request.auth`

`request.method`

`request.params`

`request.path`

The `resource` variable

The `request` variable

`request.auth`

`request.method`

`request.params`

`request.path`

The `resource` variable