Cloud Firestore নিরাপত্তা সংক্রান্ত নিয়মের জন্য শর্তাবলী লেখা

এই গাইডটি নিরাপত্তা সংক্রান্ত নিয়ম স্ট্রাকচার করা গাইডের উপর ভিত্তি করে তৈরি করা হয়েছে যাতে আপনার Cloud Firestore Security Rules-এ কীভাবে শর্ত যোগ করতে হয় তা দেখানো যায়। আপনি যদি Cloud Firestore Security Rules-এর প্রাথমিক বিষয়গুলি সম্পর্কে না জানেন, তাহলে শুরু করার নির্দেশিকা দেখুন।

Cloud Firestore Security Rules-এর প্রাথমিক বিল্ডিং ব্লক হল শর্ত। শর্ত হল একটি বুলিয়ান এক্সপ্রেশন যা নির্ধারণ করে যে কোনও নির্দিষ্ট অপারেশন অনুমতি দেওয়া উচিত নাকি অস্বীকার করা উচিত। নিরাপত্তা সংক্রান্ত নিয়ম ব্যবহার করে এমন শর্ত লিখুন যা ব্যবহারকারীর যাচাইকরণ চেক করে, ইনকামিং ডেটা যাচাই করে অথবা আপনার ডেটাবেসের অন্যান্য অংশও অ্যাক্সেস করে।

AI-এর মাধ্যমে সহায়তা পেতে, নিচের প্রম্পটটি আপনার AI কোডিং এজেন্টে (যেমন, Android Studio-তে Gemini, Antigravity, Claude Code, Codex এবং Cursor) কপি করুন। আপনি প্রম্পট কাস্টমাইজ করতে এবং আপনার এজেন্টের সাথে আইটারেট করতে পারবেন। ইনস্টলেশন সংক্রান্ত বিস্তারিত তথ্যের জন্য Firebase এজেন্ট সংক্রান্ত দক্ষতা দেখুন। 

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.

যাচাইকরণ

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

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to access documents in the "cities" collection
    // only if they are authenticated.
    match /cities/{city} {
      allow read, write: if request.auth != null;
    }
  }
}

আরেকটি সাধারণ প্যাটার্ন হল ব্যবহারকারীরা যাতে শুধুমাত্র নিজেদের ডেটা পড়তে ও লিখতে পারেন তা নিশ্চিত করা:

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure the uid of the requesting user matches name of the user
    // document. The wildcard expression {userId} makes the userId variable
    // available in rules.
    match /users/{userId} {
      allow read, update, delete: if request.auth != null && request.auth.uid == userId;
      allow create: if request.auth != null;
    }
  }
}

আপনার অ্যাপ Firebase Authentication বা Google Cloud Identity Platform ব্যবহার করলে, request.auth ভেরিয়েবলে ডেটার অনুরোধ করা ক্লায়েন্টের যাচাইকরণ সংক্রান্ত তথ্য থাকে। request.auth সম্পর্কে আরও তথ্যের জন্য, রেফারেন্স ডকুমেন্টেশন দেখুন।

ডেটা যাচাইকরণ

অনেক অ্যাপ ডেটাবেসে ডকুমেন্টের ফিল্ড হিসেবে অ্যাক্সেস কন্ট্রোল সংক্রান্ত তথ্য স্টোর করে। Cloud Firestore Security Rules ডকুমেন্ট ডেটার উপর ভিত্তি করে অ্যাক্সেস ডায়নামিকভাবে অনুমোদন বা বাতিল করতে পারে:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    match /cities/{city} {
      allow read: if resource.data.visibility == 'public';
    }
  }
}

resource ভেরিয়েবেল অনুরোধ করা ডকুমেন্টকে রেফার করে এবং resource.data হল ডকুমেন্টে স্টোর করা সব ফিল্ড ও মানের ম্যাপ। resource ভেরিয়েবল সম্পর্কে আরও তথ্যের জন্য, রেফারেন্স ডকুমেন্টেশন দেখুন।

ডেটা লেখার সময়, আপনি হয়ত ইনকামিং ডেটার সাথে আগে থেকে থাকা ডেটার তুলনা করতে চাইবেন। এই ক্ষেত্রে, আপনার রুলসেট যদি বাকি থাকা রাইট করার অনুমতি দেয়, তাহলে request.resource ভেরিয়েবলে ডকুমেন্টের ভবিষ্যৎ অবস্থা থাকে। updateটি অপারেশনের জন্য যা শুধুমাত্র ডকুমেন্ট ফিল্ডের সাবসেট পরিবর্তন করে, request.resource ভেরিয়েবলে অপারেশনের পরে মুলতুবি থাকা ডকুমেন্টের অবস্থা থাকবে। অবাঞ্ছিত বা অসঙ্গতিপূর্ণ ডেটা আপডেট প্রতিরোধ করতে আপনি request.resource-এ ফিল্ডের মান চেক করতে পারেন:

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure all cities have a positive population and
    // the name is not changed
    match /cities/{city} {
      allow update: if request.resource.data.population > 0
                    && request.resource.data.name == resource.data.name;
    }
  }
}

অন্যান্য ডকুমেন্ট অ্যাক্সেস করুন

get() এবং exists() ফাংশন ব্যবহার করে, আপনার নিরাপত্তা সংক্রান্ত নিয়ম ডেটাবেসে অন্যান্য ডকুমেন্টের সাথে ইনকামিং অনুরোধ মূল্যায়ন করতে পারে। get() এবং exists() ফাংশন দুটির ক্ষেত্রেই সম্পূর্ণভাবে নির্দিষ্ট করা ডকুমেন্ট পাথ প্রয়োজন। get() এবং exists()-এর জন্য পাথ তৈরি করতে ভেরিয়েবেল ব্যবহার করার সময়, আপনাকে $(variable) সিনট্যাক্স ব্যবহার করে ভেরিয়েবেল স্পষ্টভাবে এড়িয়ে যেতে হবে।

নিচের উদাহরণে, database ভেরিয়েবলটি ম্যাচ স্টেটমেন্ট match /databases/{database}/documents-এর মাধ্যমে ক্যাপচার করা হয়েছে এবং পাথ তৈরি করতে ব্যবহার করা হয়েছে:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      // Make sure a 'users' document exists for the requesting user before
      // allowing any writes to the 'cities' collection
      allow create: if request.auth != null && exists(/databases/$(database)/documents/users/$(request.auth.uid));

      // Allow the user to delete cities if their user document has the
      // 'admin' field set to 'true'
      allow delete: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
    }
  }
}

লেখার জন্য, আপনি getAfter() ফাংশন ব্যবহার করে কোনও ট্রানজ্যাকশন বা ব্যাচ লেখার কাজ সম্পূর্ণ হওয়ার পরে কিন্তু ট্রানজ্যাকশন বা ব্যাচ কমিট করার আগে কোনও ডকুমেন্টের স্ট্যাটাস অ্যাক্সেস করতে পারবেন। get()-এর মতো, getAfter() ফাংশন একটি সম্পূর্ণ নির্দিষ্ট করা ডকুমেন্ট পাথ নেয়। আপনি getAfter() ব্যবহার করে রাইটের সেট নির্ধারণ করতে পারেন যা ট্রানজ্যাকশন বা ব্যাচ হিসেবে একসাথে হতে হবে।

কলের সীমা অ্যাক্সেস করুন

প্রতিটি নিয়ম সেট মূল্যায়নের জন্য ডকুমেন্ট অ্যাক্সেস কলের একটি সীমা আছে:

  • সিঙ্গেল-ডকুমেন্ট অনুরোধ এবং কোয়েরি অনুরোধের জন্য ১০।

  • মাল্টি-ডকুমেন্ট রিড, ট্রানজ্যাকশন এবং ব্যাচড রাইটের জন্য ২০। আগের ১০টি অপারেশনের সীমাও প্রতিটি অপারেশনের ক্ষেত্রে প্রযোজ্য।

    যেমন, ধরুন আপনি ৩টি রাইট অপারেশন সহ একটি ব্যাচড রাইট অনুরোধ তৈরি করেছেন এবং আপনার নিরাপত্তা নিয়ম প্রতিটি রাইট যাচাই করার জন্য ২টি ডকুমেন্ট অ্যাক্সেস কল ব্যবহার করে। এই ক্ষেত্রে, প্রতিটি রাইট অপারেশন তার ১০টি অ্যাক্সেস কলের মধ্যে ২টি ব্যবহার করে এবং ব্যাচড রাইট অনুরোধ তার ২০টি অ্যাক্সেস কলের মধ্যে ৬টি ব্যবহার করে।

কোনও একটি সীমা অতিক্রম করলে, অনুমতি প্রত্যাখ্যান করা হয়েছে বলে একটি সমস্যা দেখা যায়। কিছু ডকুমেন্ট অ্যাক্সেস কল ক্যাশে করা হতে পারে এবং ক্যাশে করা কল সীমার মধ্যে গণনা করা হয় না।

এইসব সীমা কীভাবে ট্রানজ্যাকশন ও ব্যাচ করা রাইটকে প্রভাবিত করে তার বিস্তারিত ব্যাখ্যার জন্য, অ্যাটমিক অপারেশন সুরক্ষিত করা সংক্রান্ত নির্দেশিকা দেখুন।

কল ও দাম অ্যাক্সেস করুন

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

কাস্টম ফাংশন

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

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

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

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

নিয়ম ফিল্টার নয়

আপনার ডেটা সুরক্ষিত করার পরে এবং কোয়েরি লেখা শুরু করার পরে, মনে রাখবেন যে নিরাপত্তা নিয়মগুলি ফিল্টার নয়। আপনি কোনও কালেকশনের সব ডকুমেন্টের জন্য কোয়েরি লিখতে পারবেন না এবং আশা করতে পারবেন না যে Rules শুধু সেইসব ডকুমেন্টই দেখাবে যেগুলি অ্যাক্সেস করার অনুমতি বর্তমান ক্লায়েন্টের আছে।

যেমন, নিম্নলিখিত নিরাপত্তা সংক্রান্ত নিয়মটি দেখুন:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    match /cities/{city} {
      allow read: if resource.data.visibility == 'public';
    }
  }
}

প্রত্যাখ্যাত: এই নিয়ম নিম্নলিখিত কোয়েরি প্রত্যাখ্যান করে কারণ ফলাফল সেটে এমন ডকুমেন্ট থাকতে পারে যেখানে visibility, public নয়:

ওয়েব 
db.collection("cities").get()
    .then(function(querySnapshot) {
        querySnapshot.forEach(function(doc) {
            console.log(doc.id, " => ", doc.data());
    });
});

অনুমোদিত: এই নিয়ম নিম্নলিখিত কোয়েরি অনুমোদন করে কারণ where("visibility", "==", "public") ক্লজ গ্যারেন্টি দেয় যে ফলাফল সেট নিয়মের শর্ত পূরণ করে:

ওয়েব 
db.collection("cities").where("visibility", "==", "public").get()
    .then(function(querySnapshot) {
        querySnapshot.forEach(function(doc) {
            console.log(doc.id, " => ", doc.data());
        });
    });

Rules নিরাপত্তা নিয়ম প্রতিটি কোয়েরি তার সম্ভাব্য ফলাফলের ভিত্তিতে মূল্যায়ন করে এবং যদি এটি এমন কোনও ডকুমেন্ট ফেরত দিতে পারে যা পড়ার অনুমতি ক্লায়েন্টের নেই, তাহলে অনুরোধটি বাতিল করে দেয়। কোয়েরি অবশ্যই আপনার নিরাপত্তা সংক্রান্ত নিয়মের মাধ্যমে সেট করা সীমাবদ্ধতা মেনে চলতে হবে। নিরাপত্তা সংক্রান্ত নিয়ম ও কোয়েরি সম্পর্কে আরও জানতে, নিরাপদে ডেটা কোয়েরি করা দেখুন।

পরবর্তী ধাপ