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

নিরাপত্তা অ্যাপ ডেভেলপমেন্ট ধাঁধা সবচেয়ে জটিল টুকরা এক হতে পারে. বেশিরভাগ অ্যাপ্লিকেশনে, বিকাশকারীদের অবশ্যই একটি সার্ভার তৈরি এবং চালাতে হবে যা প্রমাণীকরণ (কে একজন ব্যবহারকারী) এবং অনুমোদন (একজন ব্যবহারকারী কী করতে পারে) পরিচালনা করে।

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

নিরাপত্তা নিয়ম সংস্করণ 2

মে 2019 থেকে, Firebase নিরাপত্তা নিয়মের সংস্করণ 2 এখন উপলব্ধ। নিয়মের সংস্করণ 2 পুনরাবৃত্ত ওয়াইল্ডকার্ডের আচরণ পরিবর্তন করে {name=**} । আপনি যদি সংগ্রহ গ্রুপের প্রশ্নগুলি ব্যবহার করার পরিকল্পনা করেন তবে আপনাকে অবশ্যই সংস্করণ 2 ব্যবহার করতে হবে৷ 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 ।

দ্রষ্টব্য: আপনি কেবলমাত্র সেই নথিগুলি অ্যাক্সেস করতে পারেন যা আপনার সুরক্ষা নিয়মগুলি আপনাকে বিশেষভাবে অ্যাক্সেস করার অনুমতি দেয়৷ উদাহরণস্বরূপ, উপরে দেখানো নিয়মগুলি শুধুমাত্র cities সংগ্রহের নথিগুলিতে অ্যাক্সেসের অনুমতি দেয়; ফলস্বরূপ, তারা অন্যান্য সমস্ত সংগ্রহের নথিতে অ্যাক্সেস অস্বীকার করে।

মিলে যাওয়া উপসংগ্রহ

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

রিকার্সিভ ওয়াইল্ডকার্ড

আপনি যদি ইচ্ছামত গভীর অনুক্রমের জন্য নিয়মগুলি প্রয়োগ করতে চান, তাহলে পুনরাবৃত্ত ওয়াইল্ডকার্ড সিনট্যাক্স ব্যবহার করুন, {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 ।

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

সংস্করণ 1

নিরাপত্তা বিধি ডিফল্টরূপে সংস্করণ 1 ব্যবহার করে। সংস্করণ 1-এ, পুনরাবৃত্ত ওয়াইল্ডকার্ডগুলি এক বা একাধিক পথের আইটেমগুলির সাথে মেলে৷ এগুলি একটি খালি পাথের সাথে মেলে না, তাই match /cities/{city}/{document=**} মেলে নথির সাথে সাবকলেকশনে কিন্তু cities সংগ্রহে নয়, যেখানে match /cities/{document=**} cities সংগ্রহ এবং উপসংগ্রহ।

রিকার্সিভ ওয়াইল্ডকার্ড অবশ্যই ম্যাচ স্টেটমেন্টের শেষে আসতে হবে।

সংস্করণ 2

নিরাপত্তা নিয়মের সংস্করণ 2-এ, পুনরাবৃত্ত ওয়াইল্ডকার্ড শূন্য বা তার বেশি পাথ আইটেমগুলির সাথে মেলে। match/cities/{city}/{document=**} যেকোন উপ-সংগ্রহের দস্তাবেজের সাথে cities সংগ্রহের নথির সাথে মিলে যায়।

rules_version = '2'; আপনার নিরাপত্তা নিয়মের শীর্ষে:

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

প্রতি ম্যাচ স্টেটমেন্টে আপনার কাছে সর্বাধিক একটি রিকারসিভ ওয়াইল্ডকার্ড থাকতে পারে, কিন্তু সংস্করণ 2-এ, আপনি ম্যাচ স্টেটমেন্টের যেকোনো জায়গায় এই ওয়াইল্ডকার্ড রাখতে পারেন। যেমন:

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

আপনি যদি সংগ্রহ গোষ্ঠীর প্রশ্নগুলি ব্যবহার করেন, তাহলে আপনাকে অবশ্যই সংস্করণ 2 ব্যবহার করতে হবে, সংগ্রহের গোষ্ঠীর প্রশ্নগুলি সুরক্ষিত করা দেখুন৷

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

একটি ডকুমেন্টের জন্য একাধিক 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 or subcollections.
    match /cities/{document=**} {
      allow read, write: if true;
    }
  }
}

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

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

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

সীমা	বিস্তারিত
প্রতি অনুরোধে সর্বাধিক সংখ্যক exists() , get() , এবং getAfter() কল	10 একক-নথির অনুরোধ এবং ক্যোয়ারী অনুরোধের জন্য। মাল্টি-ডকুমেন্ট রিড, লেনদেন এবং ব্যাচড রাইটের জন্য 20। 10 এর আগের সীমা প্রতিটি অপারেশনের ক্ষেত্রেও প্রযোজ্য। উদাহরণস্বরূপ, কল্পনা করুন যে আপনি 3টি লেখার ক্রিয়াকলাপ সহ একটি ব্যাচড লেখার অনুরোধ তৈরি করেছেন এবং আপনার সুরক্ষা নিয়ম প্রতিটি লেখাকে যাচাই করতে 2টি নথি অ্যাক্সেস কল ব্যবহার করে৷ এই ক্ষেত্রে, প্রতিটি লেখা তার 10টি অ্যাক্সেস কলের মধ্যে 2টি ব্যবহার করে এবং ব্যাচড লেখার অনুরোধটি তার 20টি অ্যাক্সেস কলের মধ্যে 6টি ব্যবহার করে। উভয় সীমা অতিক্রম করার ফলে একটি অনুমতি অস্বীকার ত্রুটি দেখা দেয়। কিছু নথি অ্যাক্সেস কল ক্যাশ করা হতে পারে, এবং ক্যাশে কল সীমার মধ্যে গণনা করা হয় না।
নেস্টেড match স্টেটমেন্টের সর্বোচ্চ গভীরতা	10
সর্বাধিক পাথ দৈর্ঘ্য, পাথ বিভাগে, নেস্টেড match স্টেটমেন্টের একটি সেটের মধ্যে অনুমোদিত৷	100
নেস্টেড match স্টেটমেন্টের একটি সেটের মধ্যে সর্বাধিক সংখ্যক পাথ ক্যাপচার ভেরিয়েবল অনুমোদিত৷	20
সর্বাধিক ফাংশন কল গভীরতা	20
ফাংশন আর্গুমেন্টের সর্বোচ্চ সংখ্যা	7
প্রতি ফাংশনে let ভেরিয়েবল বাইন্ডিংয়ের সর্বোচ্চ সংখ্যা	10
রিকার্সিভ বা চক্রাকার ফাংশন কলের সর্বাধিক সংখ্যা	0 (অনুমতি নেই)
প্রতি অনুরোধে মূল্যায়ন করা অভিব্যক্তির সর্বোচ্চ সংখ্যা	1,000
একটি নিয়ম সেটের সর্বোচ্চ আকার	নিয়মগুলিকে অবশ্যই দুটি আকারের সীমা মেনে চলতে হবে: Firebase কনসোল থেকে বা firebase deploy ব্যবহার করে CLI থেকে প্রকাশিত রুলসেট টেক্সট সোর্সের আকারের একটি 256 KB সীমা। কম্পাইল করা রুলসেটের আকারের একটি 250 KB সীমা যার ফলস্বরূপ যখন Firebase উৎসটি প্রক্রিয়া করে এবং এটিকে ব্যাক-এন্ডে সক্রিয় করে।

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 বিবৃতি, যার মধ্যে এমন একটি শর্ত রয়েছে যা একটি অনুরোধের অনুমতি দেয় যদি এটি সত্যে মূল্যায়ন করে।

মিলে যাওয়া পথ

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 হয়।

উপরের নিয়মে, "images/profilePhoto.png" ফাইলটি পড়া যাবে যদি হয় condition বা other_condition সত্যে মূল্যায়ন করা হয়, যখন ফাইল "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 অবজেক্টটিতে ব্যবহারকারীর অনন্য আইডি এবং Firebase Authentication পেলোডও রয়েছে request.auth অবজেক্টে, যা ডক্সের প্রমাণীকরণ বিভাগে আরও ব্যাখ্যা করা হবে।

request বস্তুর বৈশিষ্ট্যগুলির একটি সম্পূর্ণ তালিকা নীচে উপলব্ধ:

সম্পত্তি	টাইপ	বর্ণনা
auth	মানচিত্র<string, string>	যখন একজন ব্যবহারকারী লগ ইন করেন, তখন uid , ব্যবহারকারীর অনন্য আইডি এবং token প্রদান করে, Firebase Authentication JWT দাবির একটি মানচিত্র। অন্যথায়, এটি null হবে।
params	মানচিত্র<string, string>	অনুরোধের ক্যোয়ারী প্যারামিটার ধারণকারী ম্যাপ।
path	পথ	অনুরোধটি সম্পাদিত হচ্ছে এমন একটি path প্রতিনিধিত্ব করে।
resource	মানচিত্র<string, string>	নতুন সম্পদ মান, শুধুমাত্র write অনুরোধে উপস্থিত।
time	টাইমস্ট্যাম্প	একটি টাইমস্ট্যাম্প সার্ভারের প্রতিনিধিত্ব করে যে সময়ে অনুরোধটি মূল্যায়ন করা হয়।

দ্রষ্টব্য: এই বৈশিষ্ট্যগুলির জন্য বিস্তারিত ডকুমেন্টেশন Cloud Storage API রেফারেন্সের জন্য Firebase Security Rules উপলব্ধ।

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

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

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

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

resource অবজেক্টের বৈশিষ্ট্যগুলির একটি সম্পূর্ণ তালিকা নীচে উপলব্ধ:

সম্পত্তি	টাইপ	বর্ণনা
name	স্ট্রিং	বস্তুর পুরো নাম
bucket	স্ট্রিং	এই বস্তুটি যে বালতিতে থাকে তার নাম।
generation	int	এই অবজেক্টের Google Cloud Storage অবজেক্ট জেনারেশন ।
metageneration	int	Google Cloud Storage অবজেক্ট এই অবজেক্টের মেটাজেনারেশন ।
size	int	বাইটে বস্তুর আকার।
timeCreated	টাইমস্ট্যাম্প	একটি টাইমস্ট্যাম্প যা একটি বস্তু তৈরি করার সময়কে প্রতিনিধিত্ব করে।
updated	টাইমস্ট্যাম্প	একটি টাইমস্ট্যাম্প একটি বস্তুর সর্বশেষ আপডেট হওয়ার সময়কে প্রতিনিধিত্ব করে।
md5Hash	স্ট্রিং	বস্তুর একটি MD5 হ্যাশ।
crc32c	স্ট্রিং	বস্তুর একটি crc32c হ্যাশ।
etag	স্ট্রিং	এই বস্তুর সাথে যুক্ত etag।
contentDisposition	স্ট্রিং	এই বস্তুর সাথে সম্পর্কিত বিষয়বস্তুর স্বভাব।
contentEncoding	স্ট্রিং	এই বস্তুর সাথে সম্পর্কিত বিষয়বস্তু এনকোডিং।
contentLanguage	স্ট্রিং	এই বস্তুর সাথে সম্পর্কিত বিষয়বস্তুর ভাষা।
contentType	স্ট্রিং	এই বস্তুর সাথে সম্পর্কিত বিষয়বস্তুর প্রকার।
metadata	মানচিত্র<string, string>	অতিরিক্ত, বিকাশকারী নির্দিষ্ট কাস্টম মেটাডেটার মূল/মান জোড়া।

request.resource generation , metageneration , etag , timeCreated , এবং updated ব্যতীত এই সবই রয়েছে।

দ্রষ্টব্য: এই বৈশিষ্ট্যগুলির জন্য বিস্তারিত ডকুমেন্টেশন Cloud Storage API রেফারেন্সের জন্য Firebase Security Rules উপলব্ধ।

নিরাপত্তা বিধি সীমা

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

সীমা	বিস্তারিত
অনুরোধ প্রতি firestore.exists() এবং firestore.get() কলের সর্বোচ্চ সংখ্যা	2 একক-নথির অনুরোধ এবং ক্যোয়ারী অনুরোধের জন্য। এই সীমা অতিক্রম করার ফলে একটি অনুমতি অস্বীকার ত্রুটি দেখা দেয়। একই নথিতে অ্যাক্সেস কল ক্যাশে করা যেতে পারে, এবং ক্যাশে করা কল সীমার মধ্যে গণনা করা হয় না।

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

এটি সব একসাথে রেখে, আপনি একটি চিত্র স্টোরেজ সমাধানের জন্য নিয়মগুলির একটি সম্পূর্ণ উদাহরণ তৈরি করতে পারেন:

service firebase.storage {
 match /b/{bucket}/o {
   match /images {
     // Cascade read to any image type at any path
     match /{allImages=**} {
       allow read;
     }

     // 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) File name (stored in imageId wildcard variable) is less than 32 characters
     match /{imageId} {
       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 নথিতে থাকা JavaScript-এর মতো অভিব্যক্তিগুলি নিয়ে গঠিত।

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

{
  "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 , 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 থাকে। ".read": false /foo/bar/ অধীনে মিথ্যা নিয়মের এখানে কোন প্রভাব নেই, যেহেতু একটি চাইল্ড পাথ দ্বারা অ্যাক্সেস প্রত্যাহার করা যাবে না।

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

যাইহোক, .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
});

উদ্দেশ্য-C

দ্রষ্টব্য: এই Firebase পণ্যটি অ্যাপ ক্লিপ লক্ষ্যে উপলব্ধ নয়।

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

সুইফট

দ্রষ্টব্য: এই Firebase পণ্যটি অ্যাপ ক্লিপ লক্ষ্যে উপলব্ধ নয়।

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

উদ্দেশ্য-C

দ্রষ্টব্য: এই Firebase পণ্যটি অ্যাপ ক্লিপ লক্ষ্যে উপলব্ধ নয়।

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

সুইফট

দ্রষ্টব্য: এই Firebase পণ্যটি অ্যাপ ক্লিপ লক্ষ্যে উপলব্ধ নয়।

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