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

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

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

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

মৌলিক কাঠামো

Cloud Firestore

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

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

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

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

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

Cloud Storage

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

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

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

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

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

Realtime Database

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

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

{
  "rules"<<;: {>>
    "path": {
    // Allow the request if the condition for each method is t<<rue.
    >>  ".read"<<;: condit>>ion,
      ".wri<<te":>> condition,
      ".validate": condition
    }
  }
}

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

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

নিয়ম গঠন

Cloud Firestore

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

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

ম্যাচ

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

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

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

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

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

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

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

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

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

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

অনুমতি দিন

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

যদি মেথডটির জন্য allow নিয়মগুলোর কোনোটি পূরণ হয়, তাহলে অনুরোধটি অনুমোদিত হয়। এছাড়াও, যদি কোনো বৃহত্তর নিয়ম অ্যাক্সেস মঞ্জুর করে, তাহলে Security 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  req&&uest.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.aut&&h != null  request.auth.uid == "me";
    }
  }
}

ফাংশন

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

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

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 অ্যাসাইনমেন্টটি admins কালেকশনটি লুকআপ করতে বাধ্য করে। অপ্রয়োজনীয় লুকআপ ছাড়াই লেজি ইভ্যালুয়েশনের জন্য, && (AND) এবং || (OR) তুলনার শর্ট-সার্কিটিং বৈশিষ্ট্যকে কাজে লাগিয়ে দ্বিতীয় একটি ফাংশনকে কেবল তখনই কল করুন, যখন isAuthor true ( && তুলনার ক্ষেত্রে) অথবা false ( || তুলনার ক্ষেত্রে) হিসেবে দেখানো হয়।

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

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

Cloud Storage

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

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

ম্যাচ

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

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

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

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

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

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

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

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

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

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

অনুমতি দিন

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

যদি মেথডটির জন্য allow নিয়মগুলোর কোনোটি পূরণ হয়, তাহলে অনুরোধটি অনুমোদিত হয়। এছাড়াও, যদি কোনো বৃহত্তর নিয়ম অ্যাক্সেস মঞ্জুর করে, তাহলে Security 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  req&&uest.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.aut&&h != null  request.auth.uid == "me";
    }
  }
}

ফাংশন

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

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

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 অ্যাসাইনমেন্টটি admins কালেকশনটি লুকআপ করতে বাধ্য করে। অপ্রয়োজনীয় লুকআপ ছাড়াই লেজি ইভ্যালুয়েশনের জন্য, && (AND) এবং || (OR) তুলনার শর্ট-সার্কিটিং বৈশিষ্ট্যকে কাজে লাগিয়ে দ্বিতীয় একটি ফাংশনকে কেবল তখনই কল করুন, যখন isAuthor true ( && তুলনার ক্ষেত্রে) অথবা false ( || তুলনার ক্ষেত্রে) হিসেবে দেখানো হয়।

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 Security 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
          ".rea>d": "data.child('timestamp').val()  (now - 600000)",

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

উপরের উদাহরণে যেমন দেখানো হয়েছে, Realtime Database Security 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 তিন ধরনের নিয়ম (rule) রয়েছে। এই নিয়মগুলোর মধ্যে দুটি— read এবং write —একটি আগত অনুরোধের পদ্ধতির (method) উপর প্রযোজ্য হয়। validate ) নিয়মটি ডেটা কাঠামো প্রয়োগ করে এবং ডেটার ফরম্যাট ও বিষয়বস্তু যাচাই করে। একটি .write নিয়ম অ্যাক্সেস প্রদান করে কিনা, তা যাচাই করার পরেই Security 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-only) অথবা শুধুমাত্র লেখনযোগ্য (write-only) স্ট্যান্ডার্ড মেথডগুলোর ক্ষেত্রে যথাক্রমে প্রযোজ্য লেখার নিয়মগুলোকে সহজ করার জন্য read এবং write সুবিধাজনক মেথডগুলো রয়েছে।

request.params

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

request.path

` request.path হলো কাঙ্ক্ষিত resource পাথ। এই পাথটি সার্ভিসের সাপেক্ষে নির্ধারিত হয়। / -এর মতো নন-ইউআরএল সেফ ক্যারেক্টারযুক্ত পাথ সেগমেন্টগুলো ইউআরএল-এনকোড করা হয়।

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

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

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

Cloud Firestore এবং Cloud Storage Security 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 এবং resource ভেরিয়েবলগুলো সেই শর্তগুলোর প্রেক্ষাপট প্রদান করে।

request ভেরিয়েবল

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

request.auth

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

request.method

request.method টি যেকোনো স্ট্যান্ডার্ড মেথড বা একটি কাস্টম মেথড হতে পারে। এছাড়াও, শুধুমাত্র পঠনযোগ্য (read-only) অথবা শুধুমাত্র লেখনযোগ্য (write-only) স্ট্যান্ডার্ড মেথডগুলোর ক্ষেত্রে যথাক্রমে প্রযোজ্য লেখার নিয়মগুলোকে সহজ করার জন্য read এবং write সুবিধাজনক মেথডগুলো রয়েছে।

request.params

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

request.path

` request.path হলো কাঙ্ক্ষিত resource পাথ। এই পাথটি সার্ভিসের সাপেক্ষে নির্ধারিত হয়। / -এর মতো নন-ইউআরএল সেফ ক্যারেক্টারযুক্ত পাথ সেগমেন্টগুলো ইউআরএল-এনকোড করা হয়।

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

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

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

Cloud Firestore এবং Cloud Storage Security 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	ত্রয়ী অভিব্যক্তি	বাম থেকে ডানে

Realtime Database

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

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

একটি রুল ডেফিনিশনের ভেতরে বেশ কিছু সহায়ক ও পূর্ব-নির্ধারিত ভেরিয়েবল ব্যবহার করা যায়। নিচে সেগুলোর প্রত্যেকটির একটি সংক্ষিপ্ত বিবরণ দেওয়া হলো:

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

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

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

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

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

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

আপনার ডাটাবেসের যেকোনো ডেটা আপনার রুলসে ব্যবহার করা যেতে পারে। root , data , এবং newData এই প্রিডিফাইন্ড ভ্যারিয়েবলগুলো ব্যবহার করে, আপনি যেকোনো পাথকে একটি রাইট ইভেন্টের আগে বা পরের অবস্থায় অ্যাক্সেস করতে পারেন।

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

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

কোয়েরি-ভিত্তিক নিয়ম

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

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

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

নিম্নলিখিত কোয়েরিটি, যেখানে নিয়মের মধ্যে কোয়েরি প্যারামিটারগুলো অন্তর্ভুক্ত রয়েছে, সফল হবে:

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

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

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

রিড অপারেশনের মাধ্যমে কোনো ক্লায়েন্ট কী পরিমাণ ডেটা ডাউনলোড করবে, তা সীমিত করতে আপনি কোয়েরি-ভিত্তিক নিয়মও ব্যবহার করতে পারেন।

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

messages: {
  ".read": "qu&&ery.orderByKey 
            quer<y.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)

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

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

অপারেটররা

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

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

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

সহজ ও প্রোডাকশন-উপযোগী Security Rules তৈরির নির্দেশনার জন্য, বেসিক সিকিউরিটি রুলস দেখুন।