ক্লাউড ফায়ারস্টোর নিরাপত্তা নিয়মের জন্য লেখার শর্ত

এই নির্দেশিকাটি আপনার Cloud Firestore Security Rules কীভাবে শর্ত যোগ করতে হয় তা দেখানোর জন্য কাঠামোগত নিরাপত্তা বিধি নির্দেশিকা তৈরি করে। আপনি যদি Cloud Firestore Security Rules মূল বিষয়গুলির সাথে পরিচিত না হন তবে শুরু করার নির্দেশিকাটি দেখুন৷

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

প্রমাণীকরণ

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

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

যদি আপনার অ্যাপ ফায়ারবেস প্রমাণীকরণ বা Google ক্লাউড আইডেন্টিটি প্ল্যাটফর্ম ব্যবহার করে, তাহলে 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() ব্যবহার করতে পারেন লেখার সেটগুলিকে সংজ্ঞায়িত করতে যা অবশ্যই একটি লেনদেন বা ব্যাচ হিসাবে একসাথে হতে হবে।

অ্যাক্সেস কল সীমা

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

  • 10 একক-নথির অনুরোধ এবং ক্যোয়ারী অনুরোধের জন্য।

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

    উদাহরণস্বরূপ, কল্পনা করুন যে আপনি 3টি লেখার ক্রিয়াকলাপ সহ একটি ব্যাচড লেখার অনুরোধ তৈরি করেছেন এবং আপনার সুরক্ষা নিয়ম প্রতিটি লেখাকে যাচাই করতে 2টি নথি অ্যাক্সেস কল ব্যবহার করে৷ এই ক্ষেত্রে, প্রতিটি লেখা তার 10টি অ্যাক্সেস কলের মধ্যে 2টি ব্যবহার করে এবং ব্যাচড লেখার অনুরোধটি তার 20টি অ্যাক্সেস কলের মধ্যে 6টি ব্যবহার করে।

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

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

অ্যাক্সেস কল এবং মূল্য

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

কাস্টম ফাংশন

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

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

একটি ফাংশন 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();
    }
  }
}

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

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

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

উদাহরণস্বরূপ, নিম্নলিখিত নিরাপত্তা নিয়ম নিন:

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

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

পরবর্তী পদক্ষেপ