পাইপলাইন পরিচালনার জন্য নিরাপত্তা নিয়মাবলী

যদিও পাইপলাইন অপারেশনগুলো বিভিন্ন ধরনের বৈশিষ্ট্য প্রদান করে, তবে সীমাবদ্ধতা পূরণযোগ্যতা এবং নিরাপত্তা নিশ্চিত করার জন্য রুলস ইঞ্জিনটি শুধুমাত্র তুলনা (যেমন > ) এবং যৌক্তিক (যেমন or ) ফিল্টার শনাক্ত করার মধ্যে সীমাবদ্ধ।

সমর্থিত ফিল্টার এক্সপ্রেশন

আপনার নিয়ম দ্বারা নির্ধারিত সীমার মধ্যে পাইপলাইন অপারেশনগুলিকে সীমাবদ্ধ রাখতে হলে, এতে অবশ্যই ধ্রুবকের বিপরীতে লজিক্যাল এবং তুলনা অপারেটর ব্যবহার করতে হবে। রুলস ইঞ্জিন নিম্নলিখিত ফিল্টার প্রকারগুলি শনাক্ত করে:

তুলনাসমূহ: eq , neq , gt , gte , lt , lte , in , arrayContains .
যৌক্তিক: and , or ।

এখানে কয়েকটি উদাহরণ দেওয়া হলো:

where(eq("foo", 2))
where(lt("foo", 2))
documents("/user/1", "/user/2").where(...)

অনুরোধ বৈশিষ্ট্য

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

সমর্থিত বৈশিষ্ট্য

নতুন ইঞ্জিনটি নিম্নলিখিত বৈশিষ্ট্যগুলি সমর্থন করা অব্যাহত রেখেছে:

request.auth : ব্যবহারকারীর ইউআইডি এবং টোকেন ডেটা অ্যাক্সেস করুন।
request.method : অপারেশনটি শনাক্ত করে (উদাহরণস্বরূপ, get , list )।
request.path : যে রিসোর্সটি অ্যাক্সেস করা হচ্ছে তার পাথ।
request.time : অনুরোধটির সার্ভার-সাইড টাইমস্ট্যাম্প।

অসমর্থিত বৈশিষ্ট্য

মাল্টি-স্টেজ কোয়েরিতে এই মানগুলি নির্ধারণের জটিলতার কারণে, request.query এর limit , offset , এবং orderBy এর মতো প্রোপার্টিগুলি পাইপলাইন অপারেশন রুল চেকের জন্য সমর্থিত নয়।

পাইপলাইন পর্যায় পরিচালনা এবং অনুমতি

নিরাপত্তা নিয়মের মধ্যে বিভিন্ন পাইপলাইন পর্যায় রয়েছে যা নির্দিষ্ট সূক্ষ্ম ক্রিয়াকলাপের সাথে সংযুক্ত থাকে:

allow list : collection() , collectionGroup() , এবং database() ধাপ দ্বারা সক্রিয় হয়।
গেট পারমিশন allow get : এটি documents() ধাপ দ্বারা ট্রিগার হয়, যেটিকে একটি ব্যাচ get অপারেশনের মতোই বিবেচনা করা হয়।
লিটারেলস পর্যায়: literals() পর্যায়টি ডাটাবেস থেকে ডেটা পড়ে না, কিন্তু এর জন্য খরচ হতে পারে। এর অপব্যবহার রোধ করতে, এটিকে অবশ্যই এমন একটি পর্যায়ের (যেমন collection() ) সাথে যুক্ত করতে হবে যা নিয়মের মাধ্যমে যাচাই করা যায়।

মাঠ পরিবর্তনের পর্যায়

নিয়মগুলি শুধুমাত্র সংরক্ষিত ডেটার উপর কাজ করে, উদ্ভূত মানের উপর নয়। যদি কোনো পাইপলাইনে এমন পর্যায় থাকে যা ফিল্ড পরিবর্তন করে (উদাহরণস্বরূপ, add_fields(...) , replace_with(...) , select(...) , remove_fields(...) ), তাহলে সেই পর্যায়ে পৌঁছানোর পর রুলস ইঞ্জিন ফিল্টার সীমাবদ্ধতা প্রয়োগ করা বন্ধ করে দেয়। নিয়মগুলি যাতে প্রত্যাশিতভাবে কাজ করে তা নিশ্চিত করতে, আপনার ফিল্টার পর্যায়গুলিকে (অর্থাৎ where ) মূল সংরক্ষিত ডকুমেন্ট পরিবর্তন করতে পারে এমন যেকোনো পর্যায়ের আগে রাখুন।

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

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

প্রত্যাখ্যাত : এই নিয়মটি নিম্নলিখিত পাইপলাইনটি প্রত্যাখ্যান করে কারণ addFields পর্যায়টি সেইসব ডকুমেন্ট ফিল্টার করার আগে ঘটে যেখানে visibility public :

const results = await db.pipeline()
  .collection("/cities")
  // Filters after a modification stage are ignored by Rules.
  .addFields(constant(1000).as("population"))
  .where(eq(field("visibility"), constant("public")))
  .execute();

অনুমোদিত : এই নিয়মটি নিম্নলিখিত পাইপলাইনকে অনুমোদন করে কারণ where(eq(field("visibility"), constant("public"))) পর্যায়টি যেকোনো পরিবর্তন পর্যায়ের আগে ঘটে:

const results = await db.pipeline()
  .collection("/cities")
  .where(eq(field("visibility"), constant("public")))
  .addFields(constant(1000).as("population"))
  .execute();