Cloud Firestore Security Rules আপনাকে আপনার ডাটাবেসের ডকুমেন্ট এবং কালেকশনগুলিতে অ্যাক্সেস নিয়ন্ত্রণ করতে দেয়। এর নমনীয় রুল সিনট্যাক্স আপনাকে এমন নিয়ম তৈরি করার সুযোগ দেয় যা সম্পূর্ণ ডাটাবেসে সমস্ত রাইট অপারেশন থেকে শুরু করে একটি নির্দিষ্ট ডকুমেন্টের অপারেশন পর্যন্ত যেকোনো কিছুর সাথে মিল রাখতে পারে।
এই নির্দেশিকায় নিরাপত্তা নিয়মের মৌলিক সিনট্যাক্স এবং কাঠামো বর্ণনা করা হয়েছে। সম্পূর্ণ নিয়মসেট তৈরি করতে এই সিনট্যাক্সকে নিরাপত্তা নিয়মের শর্তাবলীর সাথে একত্রিত করুন।
এআই সহায়তার জন্য এআই প্রম্পট
এআই সহায়তার জন্য, নিচের প্রম্পটটি আপনার এআই কোডিং এজেন্টে (যেমন অ্যান্ড্রয়েড স্টুডিওর জেমিনি, Antigravity , ক্লড কোড, কোডেক্স এবং কার্সর) কপি করুন। আপনি প্রম্পটটি কাস্টমাইজ করতে এবং আপনার এজেন্টের সাথে পুনরাবৃত্তি করতে পারেন। বিস্তারিত ইনস্টলেশন তথ্যের জন্য ফায়ারবেস এজেন্ট স্কিলস দেখুন।
Help me use Firebase in my app.
1. Make sure that **Firebase agent skills** are installed and updated. For Claude Code, Codex, or Cursor agents, help me install the Firebase plugin. For other agents, run `npx skills add firebase/agent-skills`. Always try to use **Firebase agent skills** for Firebase-related tasks.
2. Help me write, validate, and deploy Firebase Security Rules to protect my app's Firestore data.
পরিষেবা এবং ডাটাবেস ঘোষণা
Cloud Firestore Security Rules সর্বদা নিম্নলিখিত ঘোষণা দিয়ে শুরু হয়:
service cloud.firestore {
// The {database} wildcard allows the rules to reference any database,
// but these rules are only active on databases where they are explicitly deployed.
match /databases/{database}/documents {
// ...
}
} service cloud.firestore ডিক্লারেশনটি নিয়মগুলোকে 'Rules'-এর মধ্যে সীমাবদ্ধ রাখে, যার ফলে Cloud Firestore Security Rules এবং Cloud Storage-এর মতো অন্যান্য প্রোডাক্টের নিয়মের মধ্যে কোনো সংঘাত হয় না।
match /databases/{database}/documents ডিক্লারেশনটি নির্দিষ্ট করে যে, রুলগুলো প্রজেক্টের যেকোনো Rules ডেটাবেসের সাথে মিলবে। যদিও একটি প্রজেক্টে ১০০টি পর্যন্ত ডেটাবেস থাকতে পারে, শুধুমাত্র প্রথম তৈরি হওয়া ডেটাবেসটিকেই ডিফল্ট হিসেবে নির্ধারণ করা হয়।
আপনার প্রোজেক্টের প্রতিটি নামযুক্ত ডেটাবেসের জন্য Cloud Firestore Security Rules আলাদাভাবে প্রয়োগ করা হয়। এর মানে হলো, আপনি যদি একাধিক ডেটাবেস তৈরি করেন, তবে আপনাকে প্রতিটির জন্য আলাদাভাবে নিয়মগুলি পরিচালনা এবং স্থাপন করতে হবে। আপনার আপডেটগুলি স্থাপন করার বিষয়ে বিস্তারিত নির্দেশাবলীর জন্য, "আপনার আপডেটগুলি স্থাপন করুন" দেখুন।
মৌলিক পঠন/লিখন নিয়মাবলী
মৌলিক নিয়মগুলির মধ্যে একটি 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>; } } }
শ্রেণিবদ্ধ ডেটা
রুলস-এর ডেটা ডকুমেন্টের সংগ্রহে সংগঠিত থাকে, এবং প্রতিটি ডকুমেন্ট সাব-কালেকশনের মাধ্যমে স্তরবিন্যাসকে প্রসারিত করতে পারে। নিরাপত্তা নিয়মগুলো কীভাবে স্তরবিন্যাসযুক্ত ডেটার সাথে কাজ করে, তা বোঝা গুরুত্বপূর্ণ।
এমন একটি পরিস্থিতি বিবেচনা করুন যেখানে 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 ।
তবে মনে রাখবেন যে, রিকার্সিভ ওয়াইল্ডকার্ডের আচরণ নিয়মের সংস্করণের উপর নির্ভর করে।
সংস্করণ ১
নিরাপত্তা নিয়মগুলো ডিফল্টরূপে ভার্সন ১ ব্যবহার করে। ভার্সন ১-এ, রিকার্সিভ ওয়াইল্ডকার্ডগুলো এক বা একাধিক পাথ আইটেমের সাথে মেলে। এগুলো কোনো খালি পাথের সাথে মেলে না, তাই match /cities/{city}/{document=**} সাব-কালেকশনের ডকুমেন্টগুলোর সাথে মেলে কিন্তু cities কালেকশনের ডকুমেন্টগুলোর সাথে মেলে না, যেখানে match /cities/{document=**} cities কালেকশন এবং সাব-কালেকশন উভয়ের ডকুমেন্টগুলোর সাথেই মেলে।
রিকার্সিভ ওয়াইল্ডকার্ড অবশ্যই ম্যাচ স্টেটমেন্টের শেষে আসতে হবে।
সংস্করণ ২
নিরাপত্তা নিয়মের সংস্করণ ২-এ, রিকার্সিভ ওয়াইল্ডকার্ড শূন্য বা তার বেশি পাথ আইটেমকে ম্যাচ করে। 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>; } } }
প্রতিটি ম্যাচ স্টেটমেন্টে আপনি সর্বাধিক একটি রিকার্সিভ ওয়াইল্ডকার্ড ব্যবহার করতে পারেন, কিন্তু ভার্সন ২-এ আপনি এই ওয়াইল্ডকার্ডটি ম্যাচ স্টেটমেন্টের যেকোনো জায়গায় রাখতে পারেন। উদাহরণস্বরূপ:
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>; } } }
আপনি যদি কালেকশন গ্রুপ কোয়েরি ব্যবহার করেন, তাহলে আপনাকে অবশ্যই ভার্সন ২ ব্যবহার করতে হবে, কালেকশন গ্রুপ কোয়েরি সুরক্ষিতকরণ দেখুন।
ওভারল্যাপিং ম্যাচ স্টেটমেন্ট
একটি ডকুমেন্টের পক্ষে একাধিক 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 স্টেটমেন্টের সর্বোচ্চ গভীরতা | ১০ |
নেস্টেড match স্টেটমেন্টের একটি সেটের মধ্যে অনুমোদিত সর্বোচ্চ পাথ দৈর্ঘ্য, যা পাথ সেগমেন্ট আকারে থাকে। | ১০০ |
নেস্টেড match স্টেটমেন্টের একটি সেটের মধ্যে অনুমোদিত সর্বাধিক সংখ্যক পাথ ক্যাপচার ভেরিয়েবল। | ২০ |
| ফাংশন কলের সর্বোচ্চ গভীরতা | ২০ |
| ফাংশন আর্গুমেন্টের সর্বোচ্চ সংখ্যা | ৭ |
প্রতি ফাংশনে let ভেরিয়েবল বাইন্ডিংয়ের সর্বোচ্চ সংখ্যা | ১০ |
| পুনরাবৃত্তিমূলক বা চক্রাকার ফাংশন কলের সর্বোচ্চ সংখ্যা | ০ (অনুমতি নেই) |
| প্রতি অনুরোধে মূল্যায়ন করা এক্সপ্রেশনের সর্বোচ্চ সংখ্যা | ১,০০০ |
| একটি নিয়মাবলীর সর্বোচ্চ আকার | নিয়মাবলীকে অবশ্যই দুটি আকারের সীমা মেনে চলতে হবে:
|
পরবর্তী পদক্ষেপ
- নিজস্ব নিরাপত্তা নিয়মের শর্তাবলী লিখুন।
- নিরাপত্তা বিধি নির্দেশিকাটি পড়ুন।