Cloud Firestore Security Rules আপনাকে আপনার ডাটাবেসের নথি এবং সংগ্রহগুলিতে অ্যাক্সেস নিয়ন্ত্রণ করতে দেয়। নমনীয় নিয়মের সিনট্যাক্স আপনাকে এমন নিয়ম তৈরি করতে দেয় যা যেকোনো কিছুর সাথে মেলে, সমস্ত লেখা থেকে শুরু করে সম্পূর্ণ ডাটাবেস থেকে একটি নির্দিষ্ট নথিতে অপারেশন পর্যন্ত।
এই নির্দেশিকাটি নিরাপত্তা নিয়মের মৌলিক সিনট্যাক্স এবং গঠন বর্ণনা করে। সম্পূর্ণ নিয়ম সেট তৈরি করতে এই সিনট্যাক্সকে নিরাপত্তা বিধি শর্তের সাথে একত্রিত করুন।
পরিষেবা এবং ডাটাবেস ঘোষণা
Cloud Firestore Security Rules সর্বদা নিম্নলিখিত ঘোষণা দিয়ে শুরু হয়:
service cloud.firestore {
match /databases/{database}/documents {
// ...
}
}
service cloud.firestore ঘোষণা Cloud Firestore নিয়মগুলিকে স্কোপ করে, Cloud Firestore Security Rules এবং ক্লাউড স্টোরেজের মতো অন্যান্য পণ্যগুলির জন্য নিয়মগুলির মধ্যে বিরোধ প্রতিরোধ করে৷
match /databases/{database}/documents ঘোষণাটি নির্দিষ্ট করে যে নিয়মগুলি প্রকল্পের যেকোনো Cloud Firestore ডাটাবেসের সাথে মেলে। বর্তমানে প্রতিটি প্রকল্পের (default) নামের একটি মাত্র ডাটাবেস রয়েছে।
বেসিক পড়া/লেখার নিয়ম
মৌলিক নিয়মগুলির মধ্যে একটি match স্টেটমেন্ট থাকে যা একটি নথির পথ নির্দিষ্ট করে এবং নির্দিষ্ট ডেটা পড়ার সময় একটি allow প্রকাশের বিবরণ দেয়:
service cloud.firestore {
match /databases/{database}/documents {
// Match any document in the 'cities' collection
match /cities/{city} {
allow read: if <condition>;
allow write: if <condition>;
}
}
}
সমস্ত ম্যাচ বিবৃতি নথি নির্দেশ করা উচিত, সংগ্রহ নয়. একটি ম্যাচ স্টেটমেন্ট একটি নির্দিষ্ট নথির দিকে নির্দেশ করতে পারে, যেমন match /cities/SF বা ওয়াইল্ডকার্ড ব্যবহার করে নির্দিষ্ট পথে যেকোন নথিতে নির্দেশ করতে পারে, যেমন match /cities/{city} ।
উপরের উদাহরণে, ম্যাচ স্টেটমেন্টটি {city} ওয়াইল্ডকার্ড সিনট্যাক্স ব্যবহার করে। এর অর্থ হল এই নিয়মটি cities সংগ্রহের যেকোনো নথিতে প্রযোজ্য, যেমন /cities/SF বা /cities/NYC । যখন ম্যাচ স্টেটমেন্টে allow অভিব্যক্তিগুলি মূল্যায়ন করা হয়, তখন city ভেরিয়েবল শহরের নথির নামের সাথে সমাধান করবে, যেমন SF বা NYC ।
দানাদার অপারেশন
কিছু পরিস্থিতিতে, read এবং write আরও দানাদার ক্রিয়াকলাপে ভেঙে দেওয়া দরকারী। উদাহরণ স্বরূপ, আপনার অ্যাপ নথি মোছার চেয়ে নথি তৈরিতে বিভিন্ন শর্ত প্রয়োগ করতে চাইতে পারে। অথবা আপনি একক নথি পড়ার অনুমতি দিতে পারেন তবে বড় প্রশ্নগুলি অস্বীকার করতে পারেন।
একটি read নিয়ম get এবং list এ ভাঙা যেতে পারে, যখন একটি write নিয়ম create , update এবং delete মধ্যে ভাঙা যায়:
service cloud.firestore {
match /databases/{database}/documents {
// A read rule can be divided into get and list rules
match /cities/{city} {
// Applies to single document read requests
allow get: if <condition>;
// Applies to queries and collection read requests
allow list: if <condition>;
}
// A write rule can be divided into create, update, and delete rules
match /cities/{city} {
// Applies to writes to nonexistent documents
allow create: if <condition>;
// Applies to writes to existing documents
allow update: if <condition>;
// Applies to delete operations
allow delete: if <condition>;
}
}
}
অনুক্রমিক তথ্য
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>;
}
}
}
}
When nesting match statements, the path of the inner match statement is always relative to the path of the outer match statement. নিম্নলিখিত নিয়মগুলি তাই সমতুল্য:
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() কল |
উভয় সীমা অতিক্রম করার ফলে একটি অনুমতি অস্বীকার ত্রুটি দেখা দেয়। কিছু নথি অ্যাক্সেস কল ক্যাশ করা হতে পারে, এবং ক্যাশে কল সীমার মধ্যে গণনা করা হয় না। |
নেস্টেড match স্টেটমেন্টের সর্বোচ্চ গভীরতা | 10 |
সর্বাধিক পাথ দৈর্ঘ্য, পাথ বিভাগে, নেস্টেড match স্টেটমেন্টের একটি সেটের মধ্যে অনুমোদিত৷ | 100 |
নেস্টেড match স্টেটমেন্টের একটি সেটের মধ্যে সর্বাধিক সংখ্যক পাথ ক্যাপচার ভেরিয়েবল অনুমোদিত৷ | 20 |
| সর্বাধিক ফাংশন কল গভীরতা | 20 |
| ফাংশন আর্গুমেন্টের সর্বোচ্চ সংখ্যা | 7 |
প্রতি ফাংশনে let ভেরিয়েবল বাইন্ডিংয়ের সর্বোচ্চ সংখ্যা | 10 |
| রিকার্সিভ বা চক্রাকার ফাংশন কলের সর্বাধিক সংখ্যা | 0 (অনুমতি নেই) |
| প্রতি অনুরোধে মূল্যায়ন করা অভিব্যক্তির সর্বোচ্চ সংখ্যা | 1,000 |
| একটি নিয়ম সেটের সর্বোচ্চ আকার | নিয়মগুলিকে অবশ্যই দুটি আকারের সীমা মেনে চলতে হবে:
|
পরবর্তী পদক্ষেপ
- কাস্টম নিরাপত্তা নিয়ম শর্তাবলী লিখুন.
- নিরাপত্তা নিয়ম রেফারেন্স পড়ুন.