নিরাপত্তা নিয়ম কিভাবে কাজ করে

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 স্টেটমেন্ট, যাতে এমন একটি শর্ত থাকে যা সত্য প্রমাণিত হলে কোনো অনুরোধকে অনুমতি দেয়।

নিরাপত্তা বিধি সংস্করণ ২

মে ২০১৯ থেকে, Firebase সিকিউরিটি রুলসের ভার্সন ২ এখন উপলব্ধ। রুলসের ভার্সন ২ রিকার্সিভ ওয়াইল্ডকার্ড {name=**} এর আচরণ পরিবর্তন করে। আপনি যদি কালেকশন গ্রুপ কোয়েরি ব্যবহার করার পরিকল্পনা করেন, তবে আপনাকে অবশ্যই ভার্সন ২ ব্যবহার করতে হবে। আপনার সিকিউরিটি রুলসের প্রথম লাইনে rules_version = '2'; লিখে আপনাকে অবশ্যই ভার্সন ২ বেছে নিতে হবে।

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

মিলানো পথ

সমস্ত ম্যাচ স্টেটমেন্ট অবশ্যই ডকুমেন্টকে নির্দেশ করবে, কালেকশনকে নয়। একটি ম্যাচ স্টেটমেন্ট কোনো নির্দিষ্ট ডকুমেন্টকে নির্দেশ করতে পারে, যেমন match /cities/SF , অথবা নির্দিষ্ট পাথের যেকোনো ডকুমেন্টকে নির্দেশ করার জন্য ওয়াইল্ডকার্ড ব্যবহার করতে পারে, যেমন match /cities/{city} ।

উদাহরণটিতে, ম্যাচ স্টেটমেন্টে {city} ওয়াইল্ডকার্ড সিনট্যাক্স ব্যবহার করা হয়েছে। এর মানে হলো, এই নিয়মটি cities কালেকশনের যেকোনো ডকুমেন্টের ক্ষেত্রে প্রযোজ্য, যেমন /cities/SF বা /cities/NYC । যখন ম্যাচ স্টেটমেন্টের allow এক্সপ্রেশনগুলো ইভ্যালুয়েট করা হয়, তখন city ভ্যারিয়েবলটি শহরের ডকুমেন্টের নামে রিজলভ হবে, যেমন SF বা NYC ।

মিলানো উপ-সংগ্রহ

Cloud Firestore ডেটা ডকুমেন্টের কালেকশন হিসেবে সাজানো থাকে, এবং প্রতিটি ডকুমেন্ট সাব-কালেকশনের মাধ্যমে এই স্তরবিন্যাসকে প্রসারিত করতে পারে। নিরাপত্তা বিধিগুলো স্তরবিন্যাসযুক্ত ডেটার সাথে কীভাবে কাজ করে, তা বোঝা গুরুত্বপূর্ণ।

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

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      allow read, write: if <condition>;

      // Explicitly define rules for the 'landmarks' subcollection
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}

যখন match স্টেটমেন্টগুলোকে নেস্ট করা হয়, তখন ভেতরের match স্টেটমেন্টের পাথ সর্বদা বাইরের match স্টেটমেন্টের পাথের সাপেক্ষে আপেক্ষিক হয়। অতএব, নিম্নলিখিত নিয়মসেটগুলো সমতুল্য:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city}/landmarks/{landmark} {
      allow read, write: if <condition>;
    }
  }
}

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

একটি ডকুমেন্টের পক্ষে একাধিক match স্টেটমেন্টের সাথে মিলে যাওয়া সম্ভব। যদি একাধিক allow এক্সপ্রেশন একটি রিকোয়েস্টের সাথে মিলে যায়, তবে নিম্নলিখিত শর্তগুলোর মধ্যে যেকোনো একটি true হলে অ্যাক্সেসের অনুমতি দেওয়া হয়:

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the 'cities' collection.
    match /cities/{city} {
      allow read, write: if false;
    }

    // Matches any document in the 'cities' collection.
    match /cities/{document} {
      allow read, write: if true;
    }
  }
}

উদাহরণটিতে, cities কালেকশনে সমস্ত রিড এবং রাইট অনুমোদিত হবে, কারণ দ্বিতীয় নিয়মটি সর্বদা true , যদিও প্রথম নিয়মটি সর্বদা false ।

পুনরাবৃত্তিমূলক ওয়াইল্ডকার্ড

যদি আপনি যেকোনো গভীরতার স্তরবিন্যাসে নিয়ম প্রয়োগ করতে চান, তাহলে রিকার্সিভ ওয়াইল্ডকার্ড সিনট্যাক্স, {name=**} ব্যবহার করুন:

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

রিকার্সিভ ওয়াইল্ডকার্ড সিনট্যাক্স ব্যবহার করার সময়, ওয়াইল্ডকার্ড ভেরিয়েবলটিতে সম্পূর্ণ ম্যাচিং পাথ সেগমেন্টটি থাকবে, এমনকি যদি ডকুমেন্টটি একটি গভীরভাবে নেস্টেড সাবকালেকশনের মধ্যে অবস্থিত থাকে। উদাহরণস্বরূপ, তালিকাভুক্ত নিয়মগুলি /cities/SF/landmarks/coit_tower এ অবস্থিত একটি ডকুমেন্টের সাথে মিলবে, এবং document ভেরিয়েবলের মান হবে SF/landmarks/coit_tower ।

তবে মনে রাখবেন যে, রিকার্সিভ ওয়াইল্ডকার্ডের আচরণ নিয়মের সংস্করণের উপর নির্ভর করে।

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{city}/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the songs collection group
    match /{path=**}/songs/{song} {
      allow read, write: if <condition>;
    }
  }
}

আপনি যদি কালেকশন গ্রুপ কোয়েরি ব্যবহার করেন, তাহলে আপনাকে অবশ্যই ভার্সন ২ ব্যবহার করতে হবে, কালেকশন গ্রুপ কোয়েরি সুরক্ষিতকরণ দেখুন।

নিরাপত্তা নিয়মের সীমা

নিরাপত্তা বিধি নিয়ে কাজ করার সময় নিম্নলিখিত সীমাগুলো লক্ষ্য করুন:

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 স্টেটমেন্ট, যাতে এমন একটি শর্ত থাকে যা সত্য প্রমাণিত হলে কোনো অনুরোধকে অনুমতি দেয়।

মিলানো পথ

Cloud Storage Security Rules Cloud Storage ফাইল অ্যাক্সেস করার জন্য ব্যবহৃত ফাইল পাথগুলো match । রুলগুলো সুনির্দিষ্ট পাথ বা ওয়াইল্ডকার্ড পাথ match পারে এবং রুলগুলো নেস্টেডও হতে পারে। যদি কোনো ম্যাচ রুল কোনো রিকোয়েস্ট মেথডকে অনুমোদন না করে, অথবা শর্তটি ফলস false হয়, তাহলে রিকোয়েস্টটি প্রত্যাখ্যান করা হয়।

সঠিক মিল

// Exact match for "images/profilePhoto.png"
match /images/profilePhoto.png {
  allow write: if <condition>;
}

// Exact match for "images/croppedProfilePhoto.png"
match /images/croppedProfilePhoto.png {
  allow write: if <other_condition>;
}

নেস্টেড ম্যাচ

// Partial match for files that start with "images"
match /images {
  // Exact match for "images/profilePhoto.png"
  match /profilePhoto.png {
    allow write: if <condition>;
  }

  // Exact match for "images/croppedProfilePhoto.png"
  match /croppedProfilePhoto.png {
    allow write: if <other_condition>;
  }
}

ওয়াইল্ডকার্ড ম্যাচ

ওয়াইল্ডকার্ড ব্যবহার করে কোনো প্যাটার্ন match জন্যও নিয়ম ব্যবহার করা যেতে পারে। ওয়াইল্ডকার্ড হলো একটি নামযুক্ত ভেরিয়েবল যা profilePhoto.png এর মতো একটি একক স্ট্রিং, অথবা images/profilePhoto.png মতো একাধিক পাথ সেগমেন্টকে বোঝায়।

ওয়াইল্ডকার্ডের নামের চারপাশে দ্বিতীয় বন্ধনী (কার্লি ব্র্যাকেট) যোগ করে একটি ওয়াইল্ডকার্ড তৈরি করা হয়, যেমন {string} । একাধিক সেগমেন্টের ওয়াইল্ডকার্ড ঘোষণা করার জন্য, ওয়াইল্ডকার্ডের নামের সাথে =** যোগ করতে হয়, যেমন {path=**} ।

// Partial match for files that start with "images"
match /images {
  // Exact match for "images/*"
  // e.g. images/profilePhoto.png is matched
  match /{imageId} {
    // This rule only matches a single path segment (*)
    // imageId is a string that contains the specific segment matched
    allow read: if <condition>;
  }

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

যদি একাধিক নিয়ম একটি ফাইলের সাথে মিলে যায়, তাহলে ফলাফলটি হবে সমস্ত নিয়মের মূল্যায়নের ফলাফলের OR । অর্থাৎ, ফাইলটির সাথে মিলে যাওয়া যেকোনো নিয়মের মূল্যায়ন যদি ' true হয়, তাহলে ফলাফলটিও true হবে।

নিয়ম অনুযায়ী, condition অথবা other_condition যেকোনো একটির মান 'true' হলে 'images/profilePhoto.png' ফাইলটি পড়া যাবে, অপরদিকে 'images/users/user:12345/profilePhoto.png' ফাইলটি শুধুমাত্র other_condition এর ফলাফলের উপর নির্ভরশীল।

একটি ওয়াইল্ডকার্ড ভেরিয়েবলকে match প্রোভাইড ফাইলের নাম বা পাথ অথরাইজেশনের ভেতর থেকে রেফারেন্স করা যেতে পারে:

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

Cloud Storage Security Rules ক্রমান্বয়ে কার্যকর হয় না, এবং নিয়মগুলো কেবল তখনই মূল্যায়ন করা হয় যখন অনুরোধের পাথটি নির্দিষ্ট নিয়মযুক্ত কোনো পাথের সাথে মিলে যায়।

মূল্যায়নের অনুরোধ

Cloud Storage পাঠানো request ব্যবহার করে আপলোড, ডাউনলোড, মেটাডেটা পরিবর্তন এবং ডিলিট মূল্যায়ন করা হয়। request ' ভেরিয়েবলটিতে অনুরোধটি সম্পাদনের পাথ, অনুরোধটি প্রাপ্তির সময় এবং অনুরোধটি রাইট হলে নতুন resource ভ্যালু অন্তর্ভুক্ত থাকে। এছাড়াও HTTP হেডার এবং অথেনটিকেশন স্টেটও অন্তর্ভুক্ত থাকে।

request অবজেক্টটিতে request.auth অবজেক্টের মধ্যে ব্যবহারকারীর ইউনিক আইডি এবং Firebase Authentication পেলোডও থাকে, যা ডক্সের `Authentication` অংশে আরও বিস্তারিতভাবে ব্যাখ্যা করা হবে।

request অবজেক্টের প্রপার্টিগুলোর একটি সম্পূর্ণ তালিকা নিচে দেওয়া হলো:

সম্পদ মূল্যায়ন

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

Cloud Storage জন্য Firebase Security Rules resource অবজেক্টে ফাইল মেটাডেটা প্রদান করে, যেখানে একটি Cloud Storage অবজেক্টে প্রদর্শিত মেটাডেটার কী/ভ্যালু পেয়ার থাকে। ডেটার অখণ্ডতা নিশ্চিত করার জন্য read বা write অনুরোধের সময় এই বৈশিষ্ট্যগুলি পরীক্ষা করা যেতে পারে।

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

resource অবজেক্টের প্রোপার্টিগুলোর একটি পূর্ণাঙ্গ তালিকা উপলব্ধ আছে:

request.resource generation , metageneration , etag , timeCreated এবং updated ছাড়া এই সবগুলোই থাকে।

নিরাপত্তা নিয়মের সীমা

নিরাপত্তা বিধি নিয়ে কাজ করার সময় নিম্নলিখিত সীমাগুলো লক্ষ্য করুন:

সম্পূর্ণ উদাহরণ

সবকিছু একত্রিত করে, আপনি একটি ইমেজ স্টোরেজ সলিউশনের জন্য নিয়মাবলীর একটি পূর্ণাঙ্গ উদাহরণ তৈরি করতে পারেন:

service firebase.storage {
 match /b/{bucket}/o {
   match /images {
     // Allow write files to the path "images/*", subject to the constraints:
     // 1) File is less than 5MB
     // 2) Content type is an image
     // 3) Uploaded content type matches existing content type
     // 4) Filename (stored in imageId wildcard variable) is less than 32 characters
     match /{imageId} {
       allow read;
       allow write: if request.resource.size < 5 * 1024 * 1024
                    && request.resource.contentType.matches('image/.*')
                    && request.resource.contentType == resource.contentType
                    && imageId.size() < 32
     }
   }
 }
}

Realtime Database

মৌলিক কাঠামো

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

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

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

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

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

পথের ক্ষেত্রে নিয়ম কীভাবে প্রযোজ্য হয়

Realtime Database , Security Rules অ্যাটমিকভাবে প্রয়োগ হয়, যার অর্থ হলো উচ্চ-স্তরের প্যারেন্ট নোডের নিয়মগুলি আরও সূক্ষ্ম চাইল্ড নোডের নিয়মগুলিকে ওভাররাইড করে এবং একটি গভীরতর নোডের নিয়ম তার প্যারেন্ট পাথে অ্যাক্সেস দিতে পারে না। আপনি যদি ইতিমধ্যেই কোনো একটি প্যারেন্ট পাথের জন্য অ্যাক্সেস দিয়ে থাকেন, তাহলে আপনার ডেটাবেস কাঠামোর একটি গভীরতর পাথে অ্যাক্সেস পরিমার্জন বা প্রত্যাহার করতে পারবেন না।

নিম্নলিখিত নিয়মগুলো বিবেচনা করুন:

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          // ignored, since read was allowed already
          ".read": false
        }
     }
  }
}

এই নিরাপত্তা কাঠামোটি /bar/ থেকে পড়ার অনুমতি দেয় যখনই /foo/ তে true মানের একটি চাইল্ড ' baz থাকে। /foo/bar/ এর অধীনে থাকা ".read": false নিয়মটি এখানে কার্যকর নয়, কারণ একটি চাইল্ড পাথ দ্বারা অ্যাক্সেস প্রত্যাহার করা যায় না।

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

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

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

{
  "rules": {
    "records": {
      "rec1": {
        ".read": true
      },
      "rec2": {
        ".read": false
      }
    }
  }
}

নিয়মগুলো যে অ্যাটমিকভাবে মূল্যায়ন করা হয়, তা না বুঝলে মনে হতে পারে যে /records/ পাথটি ফেচ করলে rec1 রিটার্ন হবে কিন্তু rec2 হবে না। তবে, প্রকৃত ফলাফলটি হলো একটি এরর:

var db = firebase.database();
db.ref("records").once("value", function(snap) {
  // success method is not called
}, function(err) {
  // error callback triggered with PERMISSION_DENIED
});

FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[_ref child:@"records"] observeSingleEventOfType:FIRDataEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
  // success block is not called
} withCancelBlock:^(NSError * _Nonnull error) {
  // cancel block triggered with PERMISSION_DENIED
}];

var ref = FIRDatabase.database().reference()
ref.child("records").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // success block is not called
}, withCancelBlock: { error in
    // cancel block triggered with PERMISSION_DENIED
})

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // success method is not called
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback triggered with PERMISSION_DENIED
  });
});

curl https://docs-examples.firebaseio.com/rest/records/
# response returns a PERMISSION_DENIED error

যেহেতু /records/ এ রিড অপারেশনটি অ্যাটমিক, এবং /records/ অধীনে থাকা সমস্ত ডেটাতে অ্যাক্সেস দেওয়ার মতো কোনো রিড রুল নেই, তাই এটি একটি PERMISSION_DENIED এরর দেবে। যদি আমরা আমাদের Firebase কনসোলের সিকিউরিটি সিমুলেটরে এই রুলটি ইভ্যালুয়েট করি, তাহলে আমরা দেখতে পাব যে রিড অপারেশনটি ডিনাই করা হয়েছে:

Attempt to read /records with auth=Success(null)
    /
    /records

No .read rule allowed the operation.
Read was denied.

অপারেশনটি প্রত্যাখ্যান করা হয়েছিল কারণ /records/ পাথে অ্যাক্সেসের জন্য কোনো রিড রুল ছিল না, কিন্তু লক্ষ্য করুন যে rec1 এর জন্য রুলটি কখনোই মূল্যায়ন করা হয়নি কারণ এটি আমাদের অনুরোধ করা পাথে ছিল না। rec1 ফেচ করতে, আমাদের এটিকে সরাসরি অ্যাক্সেস করতে হবে:

var db = firebase.database();
db.ref("records/rec1").once("value", function(snap) {
  // SUCCESS!
}, function(err) {
  // error callback is not called
});

FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];

var ref = FIRDatabase.database().reference()
ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // SUCCESS!
})

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records/rec1");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // SUCCESS!
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback is not called
  }
});

curl https://docs-examples.firebaseio.com/rest/records/rec1
# SUCCESS!

অবস্থান পরিবর্তনশীল

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