Realtime Database-এর নিরাপত্তা সংক্রান্ত নিয়মে শর্ত ব্যবহার করা

এই গাইডটি Firebase নিরাপত্তা নিয়মের মূল ভাষা শিখুন গাইডের উপর ভিত্তি করে তৈরি করা হয়েছে যাতে আপনার Firebase রিয়েলটাইম ডেটাবেস নিরাপত্তা নিয়মে কীভাবে শর্ত যোগ করতে হয় তা দেখানো যায়।

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

  • ব্যবহারকারীর পরিচয় যাচাইকরণ চেক করুন
  • নতুন জমা দেওয়া ডেটার সাথে আগে থেকে থাকা ডেটা মূল্যায়ন করা
  • আপনার ডেটাবেসের বিভিন্ন অংশ অ্যাক্সেস ও তুলনা করুন
  • ইনকামিং ডেটা যাচাই করা
  • নিরাপত্তা সংক্রান্ত লজিকের জন্য ইনকামিং কোয়েরির স্ট্রাকচার ব্যবহার করা

পাথ সেগমেন্ট ক্যাপচার করতে $ ভেরিয়েবল ব্যবহার করা

আপনি $ প্রিফিক্স সহ ক্যাপচার ভেরিয়েবল ঘোষণা করে, রিড বা রাইটের জন্য পাথের অংশ ক্যাপচার করতে পারবেন। এটি ওয়াইল্ড কার্ড হিসেবে কাজ করে এবং নিয়মের শর্তের মধ্যে ব্যবহার করার জন্য সেই 'কী'-এর ভ্যালু স্টোর করে:

{
  "rules": {
    "rooms": {
      // this rule applies to any child of /rooms/, the key for each room id
      // is stored inside $room_id variable for reference
      "$room_id": {
        "topic": {
          // the room's topic can be changed if the room id has "public" in it
          ".write": "$room_id.contains('public')"
        }
      }
    }
  }
}

ডায়নামিক $ ভেরিয়েবল কনস্ট্যান্ট পাথ নামের সাথেও ব্যবহার করা যেতে পারে। এই উদাহরণে, আমরা $other ভেরিয়েবল ব্যবহার করে একটি .validate নিয়ম ঘোষণা করছি যা নিশ্চিত করে যে widget-এর title এবং color ছাড়া অন্য কোনও চাইল্ড নেই। এমন কোনও রাইট অপারেশন যা অতিরিক্ত চাইল্ড তৈরি করবে, তা ব্যর্থ হবে।

{
  "rules": {
    "widget": {
      // a widget can have a title or color attribute
      "title": { ".validate": true },
      "color": { ".validate": true },

      // but no other child paths are allowed
      // in this case, $other means any key excluding "title" and "color"
      "$other": { ".validate": false }
    }
  }
}

যাচাইকরণ

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

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

Firebase Authentication, Firebase Realtime Database-এর সাথে ইন্টিগ্রেট করে যাতে আপনি শর্ত ব্যবহার করে প্রতি ব্যবহারকারী ভিত্তিতে ডেটা অ্যাক্সেস কন্ট্রোল করতে পারেন। ব্যবহারকারী যাচাইকরণ করলে, আপনার Realtime Database নিরাপত্তা নিয়মের auth ভেরিয়েবল ব্যবহারকারীর তথ্য দিয়ে পূরণ করা হবে। এই তথ্যের মধ্যে তাদের অনন্য শনাক্তকারী (uid) এবং লিঙ্ক করা অ্যাকাউন্ট ডেটা, যেমন Facebook আইডি বা ইমেল ঠিকানা এবং অন্যান্য তথ্য অন্তর্ভুক্ত থাকে। আপনি যদি একটি কাস্টম প্রমাণীকরণ প্রদানকারী বাস্তবায়ন করেন, তাহলে আপনি আপনার ব্যবহারকারীর প্রমাণীকরণ পেলোডে আপনার নিজস্ব ক্ষেত্র যোগ করতে পারেন।

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

auth ভেরিয়েবেল

যাচাইকরণ হওয়ার আগে নিয়মে আগে থেকে নির্ধারিত auth ভেরিয়েবেল নাল থাকে।

Firebase Authentication-এর মাধ্যমে কোনও ব্যবহারকারীকে যাচাই করা হলে এতে নিম্নলিখিত অ্যাট্রিবিউট থাকবে:

প্রোভাইডার যাচাইকরণ পদ্ধতি ব্যবহার করা হয়েছে ("পাসওয়ার্ড", "বেনামী", "facebook", "github", "google", বা "twitter")।
uid একটি অনন্য ব্যবহারকারী আইডি, যা সব পরিষেবা প্রদানকারীর ক্ষেত্রে অনন্য হওয়ার গ্যারেন্টি দেওয়া হয়।
টোকেন Firebase Auth ID টোকেনের কন্টেন্ট। আরও বিবরণের জন্য auth.token-এর রেফারেন্স ডকুমেন্টেশন দেখুন।

এখানে একটি উদাহরণস্বরূপ নিয়ম দেওয়া হল যা auth ভেরিয়েবল ব্যবহার করে এটি নিশ্চিত করে যে প্রত্যেক ব্যবহারকারী শুধুমাত্র ব্যবহারকারী-নির্দিষ্ট পাথে লিখতে পারবেন:

{
  "rules": {
    "users": {
      "$user_id": {
        // grants write access to the owner of this user account
        // whose uid must exactly match the key ($user_id)
        ".write": "$user_id === auth.uid"
      }
    }
  }
}

যাচাইকরণের শর্তাবলী পূরণ করার জন্য আপনার ডেটাবেস স্ট্রাকচার করা

আপনার ডেটাবেস এমনভাবে সাজালে সাধারণত সুবিধা হয় যাতে Security Rules লেখা সহজ হয়। Realtime Database-এ ব্যবহারকারীর ডেটা স্টোর করার একটি সাধারণ প্যাটার্ন হল আপনার সব ব্যবহারকারীর ডেটা একটি users নোডে স্টোর করা যার চাইল্ড হল প্রতিটি ব্যবহারকারীর জন্য uid ভ্যালু। আপনি যদি এই ডেটাতে অ্যাক্সেস সীমাবদ্ধ করতে চান যাতে শুধুমাত্র লগ-ইন করা ব্যবহারকারী তার নিজের ডেটা দেখতে পারেন, তাহলে আপনার নিয়মগুলি এইরকম দেখাবে।

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth !== null && auth.uid === $uid"
      }
    }
  }
}

Authentication Custom Claims-এর সাথে কাজ করা

যেসব অ্যাপের ক্ষেত্রে বিভিন্ন ব্যবহারকারীর জন্য কাস্টম অ্যাক্সেস কন্ট্রোল প্রয়োজন, Firebase Authentication সেগুলির ক্ষেত্রে ডেভেলপাররা Firebase ব্যবহারকারীর উপর দাবি সেট করতে পারেন। আপনার নিয়মের auth.token ভেরিয়েবলে এইসব দাবি অ্যাক্সেস করা যায়। এখানে এমন নিয়মের উদাহরণ দেওয়া হল যা hasEmergencyTowel কাস্টম দাবি ব্যবহার করে:

{
  "rules": {
    "frood": {
      // A towel is about the most massively useful thing an interstellar
      // hitchhiker can have
      ".read": "auth.token.hasEmergencyTowel === true"
    }
  }
}

নিজেদের কাস্টম যাচাইকরণ টোকেন তৈরি করা ডেভেলপাররা ঐচ্ছিকভাবে এইসব টোকেনে দাবি যোগ করতে পারেন। এইসব দাবি আপনার নিয়মের auth.token ভেরিয়েবলে উপলভ্য।

আগে থেকে থাকা ডেটা বনাম নতুন ডেটা

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

উদাহরণস্বরূপ, এই নিয়ম আমাদের নতুন রেকর্ড তৈরি করতে বা আগে থেকে থাকা রেকর্ড মুছে দিতে অনুমতি দেবে, কিন্তু আগে থেকে থাকা নন-নাল ডেটাতে পরিবর্তন করতে দেবে না:

// we can write as long as old data or new data does not exist
// in other words, if this is a delete or a create, but not an update
".write": "!data.exists() || !newData.exists()"

অন্যান্য পাথে ডেটা রেফারেন্স করা

নিয়মের মাপকাঠি হিসেবে যেকোনও ডেটা ব্যবহার করা যেতে পারে। আগে থেকে নির্ধারিত ভেরিয়েবল root, data এবং newData ব্যবহার করে, আমরা যেকোনও পাথ অ্যাক্সেস করতে পারি, কারণ এটি কোনও রাইট ইভেন্টের আগে বা পরে থাকবে।

এই উদাহরণটি বিবেচনা করুন, যা রাইট অপারেশন করার অনুমতি দেয় যতক্ষণ না /allow_writes/ নোডের মান true হয়, পেরেন্ট নোডে কোনও readOnly ফ্ল্যাগ সেট করা থাকে না এবং নতুন লেখা ডেটাতে foo নামের একটি চাইল্ড থাকে:

".write": "root.child('allow_writes').val() === true &&
          !data.parent().child('readOnly').exists() &&
          newData.child('foo').exists()"

ডেটা যাচাই করা হচ্ছে

ডেটা স্ট্রাকচার এনফোর্স করা এবং ডেটার ফর্ম্যাট ও কন্টেন্ট যাচাই করার কাজ .validate নিয়ম ব্যবহার করে করা উচিত, যা শুধুমাত্র .write নিয়ম অ্যাক্সেস মঞ্জুর করার পরে রান করে। নিচে একটি স্যাম্পেল .validate নিয়মের সংজ্ঞা দেওয়া হল যা শুধুমাত্র ১৯০০-২০৯৯ সালের মধ্যে YYYY-MM-DD ফর্ম্যাটে তারিখ লেখার অনুমতি দেয়, যা রেগুলার এক্সপ্রেশন ব্যবহার করে চেক করা হয়।

".validate": "newData.isString() &&
              newData.val().matches(/^(19|20)[0-9][0-9][-\\/. ](0[1-9]|1[012])[-\\/. ](0[1-9]|[12][0-9]|3[01])$/)"

.validate নিয়ম হল একমাত্র নিরাপত্তা সংক্রান্ত নিয়ম যা ক্যাসকেড করে না। কোনও চাইল্ড রেকর্ডে কোনও যাচাইকরণ নিয়ম কাজ না করলে, সম্পূর্ণ রাইট অপারেশন বাতিল করা হবে। এছাড়াও, ডেটা মুছে ফেলার সময় (অর্থাৎ, নতুন ভ্যালু null হিসেবে লেখা হলে) যাচাইকরণ সংক্রান্ত সংজ্ঞা উপেক্ষা করা হয়।

এগুলি তুচ্ছ বিষয় বলে মনে হতে পারে, কিন্তু আসলে এগুলি শক্তিশালী Firebase Realtime Database Security Rules লেখার জন্য গুরুত্বপূর্ণ ফিচার। নিম্নলিখিত নিয়মগুলি বিবেচনা করুন:

{
  "rules": {
    // write is allowed for all paths
    ".write": true,
    "widget": {
      // a valid widget must have attributes "color" and "size"
      // allows deleting widgets (since .validate is not applied to delete rules)
      ".validate": "newData.hasChildren(['color', 'size'])",
      "size": {
        // the value of "size" must be a number between 0 and 99
        ".validate": "newData.isNumber() &&
                      newData.val() >= 0 &&
                      newData.val() <= 99"
      },
      "color": {
        // the value of "color" must exist as a key in our mythical
        // /valid_colors/ index
        ".validate": "root.child('valid_colors/' + newData.val()).exists()"
      }
    }
  }
}

এই ভেরিয়েন্টের কথা মাথায় রেখে, নিম্নলিখিত রাইট অপারেশনের ফলাফল দেখুন:

জাভাস্ক্রিপ্ট
var ref = db.ref("/widget");

// PERMISSION_DENIED: does not have children color and size
ref.set('foo');

// PERMISSION DENIED: does not have child color
ref.set({size: 22});

// PERMISSION_DENIED: size is not a number
ref.set({ size: 'foo', color: 'red' });

// SUCCESS (assuming 'blue' appears in our colors list)
ref.set({ size: 21, color: 'blue'});

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child('size').set(99);
Objective-C
মনে রাখবেন: এই Firebase প্রোডাক্ট অ্যাপ ক্লিপ টার্গেটে উপলভ্য নয়। 
FIRDatabaseReference *ref = [[[FIRDatabase database] reference] child: @"widget"];

// PERMISSION_DENIED: does not have children color and size
[ref setValue: @"foo"];

// PERMISSION DENIED: does not have child color
[ref setValue: @{ @"size": @"foo" }];

// PERMISSION_DENIED: size is not a number
[ref setValue: @{ @"size": @"foo", @"color": @"red" }];

// SUCCESS (assuming 'blue' appears in our colors list)
[ref setValue: @{ @"size": @21, @"color": @"blue" }];

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
[[ref child:@"size"] setValue: @99];
Swift
মনে রাখবেন: এই Firebase প্রোডাক্ট অ্যাপ ক্লিপ টার্গেটে উপলভ্য নয়। 
var ref = FIRDatabase.database().reference().child("widget")

// PERMISSION_DENIED: does not have children color and size
ref.setValue("foo")

// PERMISSION DENIED: does not have child color
ref.setValue(["size": "foo"])

// PERMISSION_DENIED: size is not a number
ref.setValue(["size": "foo", "color": "red"])

// SUCCESS (assuming 'blue' appears in our colors list)
ref.setValue(["size": 21, "color": "blue"])

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child("size").setValue(99);
জাভা
FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("widget");

// PERMISSION_DENIED: does not have children color and size
ref.setValue("foo");

// PERMISSION DENIED: does not have child color
ref.child("size").setValue(22);

// PERMISSION_DENIED: size is not a number
Map<String,Object> map = new HashMap<String, Object>();
map.put("size","foo");
map.put("color","red");
ref.setValue(map);

// SUCCESS (assuming 'blue' appears in our colors list)
map = new HashMap<String, Object>();
map.put("size", 21);
map.put("color","blue");
ref.setValue(map);

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child("size").setValue(99);
REST
# PERMISSION_DENIED: does not have children color and size
curl -X PUT -d 'foo' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# PERMISSION DENIED: does not have child color
curl -X PUT -d '{"size": 22}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# PERMISSION_DENIED: size is not a number
curl -X PUT -d '{"size": "foo", "color": "red"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# SUCCESS (assuming 'blue' appears in our colors list)
curl -X PUT -d '{"size": 21, "color": "blue"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# If the record already exists and has a color, this will
# succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
# will fail to validate
curl -X PUT -d '99' \
https://docs-examples.firebaseio.com/rest/securing-data/example/size.json

এখন একই স্ট্রাকচার দেখা যাক, তবে .validate-এর পরিবর্তে .write নিয়ম ব্যবহার করে:

{
  "rules": {
    // this variant will NOT allow deleting records (since .write would be disallowed)
    "widget": {
      // a widget must have 'color' and 'size' in order to be written to this path
      ".write": "newData.hasChildren(['color', 'size'])",
      "size": {
        // the value of "size" must be a number between 0 and 99, ONLY IF WE WRITE DIRECTLY TO SIZE
        ".write": "newData.isNumber() && newData.val() >= 0 && newData.val() <= 99"
      },
      "color": {
        // the value of "color" must exist as a key in our mythical valid_colors/ index
        // BUT ONLY IF WE WRITE DIRECTLY TO COLOR
        ".write": "root.child('valid_colors/'+newData.val()).exists()"
      }
    }
  }
}

এই ভেরিয়েন্টে, নিম্নলিখিত যেকোনও অপারেশন সফল হবে:

জাভাস্ক্রিপ্ট
var ref = new Firebase(URL + "/widget");

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
ref.set({size: 99999, color: 'red'});

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.child('size').set(99);
Objective-C
মনে রাখবেন: এই Firebase প্রোডাক্ট অ্যাপ ক্লিপ টার্গেটে উপলভ্য নয়। 
Firebase *ref = [[Firebase alloc] initWithUrl:URL];

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
[ref setValue: @{ @"size": @9999, @"color": @"red" }];

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
[[ref childByAppendingPath:@"size"] setValue: @99];
Swift
মনে রাখবেন: এই Firebase প্রোডাক্ট অ্যাপ ক্লিপ টার্গেটে উপলভ্য নয়। 
var ref = Firebase(url:URL)

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
ref.setValue(["size": 9999, "color": "red"])

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.childByAppendingPath("size").setValue(99)
জাভা
Firebase ref = new Firebase(URL + "/widget");

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
Map<String,Object> map = new HashMap<String, Object>();
map.put("size", 99999);
map.put("color", "red");
ref.setValue(map);

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.child("size").setValue(99);
REST
# ALLOWED? Even though size is invalid, widget has children color and size,
# so write is allowed and the .write rule under color is ignored
curl -X PUT -d '{size: 99999, color: "red"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# ALLOWED? Works even if widget does not exist, allowing us to create a widget
# which is invalid and does not have a valid color.
# (allowed by the write rule under "color")
curl -X PUT -d '99' \
https://docs-examples.firebaseio.com/rest/securing-data/example/size.json

এটি .write এবং .validate নিয়মের মধ্যে পার্থক্য ব্যাখ্যা করে। যেমন দেখানো হয়েছে, এই সব নিয়ম .validate ব্যবহার করে লিখতে হবে, newData.hasChildren() নিয়মের ক্ষেত্রে ব্যতিক্রম হতে পারে, যা নির্ভর করবে মুছে দেওয়ার অনুমতি দেওয়া হবে কিনা তার উপর।

কোয়েরি-ভিত্তিক নিয়ম

যদিও আপনি নিয়মকে ফিল্টার হিসেবে ব্যবহার করতে পারবেন না, তবে নিয়মে কোয়েরি প্যারামিটার ব্যবহার করে ডেটার সাবসেটে অ্যাক্সেস সীমিত করতে পারবেন। কোয়েরি প্যারামিটারের উপর ভিত্তি করে রিড বা রাইট অ্যাক্সেস দিতে আপনার নিয়মে query. এক্সপ্রেশন ব্যবহার করুন।

যেমন, নিম্নলিখিত কোয়েরি-ভিত্তিক নিয়ম ব্যবহারকারী-ভিত্তিক নিরাপত্তা নিয়ম এবং কোয়েরি-ভিত্তিক নিয়ম ব্যবহার করে baskets সংগ্রহে ডেটা অ্যাক্সেস সীমাবদ্ধ করে শুধুমাত্র অ্যাক্টিভ ব্যবহারকারীর মালিকানাধীন শপিং বাস্কেটে:

"baskets": {
  ".read": "auth.uid !== null &&
            query.orderByChild === 'owner' &&
            query.equalTo === auth.uid" // restrict basket access to owner of basket
}

নিম্নলিখিত কোয়েরি, যার মধ্যে নিয়মে কোয়েরি প্যারামিটার অন্তর্ভুক্ত আছে, সেটি সফল হবে:

db.ref("baskets").orderByChild("owner")
                 .equalTo(auth.currentUser.uid)
                 .on("value", cb)                 // Would succeed

তবে, নিয়মে উল্লেখ করা প্যারামিটারগুলি অন্তর্ভুক্ত না করা কোয়েরিগুলি PermissionDenied সমস্যার সাথে ব্যর্থ হবে:

db.ref("baskets").on("value", cb)                 // Would fail with PermissionDenied

এছাড়াও, আপনি কোয়েরি-ভিত্তিক নিয়ম ব্যবহার করে, রিড অপারেশনের মাধ্যমে ক্লায়েন্ট কতটা ডেটা ডাউনলোড করতে পারবে তা সীমিত করতে পারবেন।

যেমন, নিম্নলিখিত নিয়মটি অগ্রাধিকারের ক্রম অনুযায়ী কোনও কোয়েরির প্রথম ১০০০টি ফলাফলের রিড অ্যাক্সেস সীমিত করে:

messages: {
  ".read": "query.orderByKey &&
            query.limitToFirst <= 1000"
}

// Example queries:

db.ref("messages").on("value", cb)                // Would fail with PermissionDenied

db.ref("messages").limitToFirst(1000)
                  .on("value", cb)                // Would succeed (default order by key)

রিয়েল-টাইম ডেটাবেস নিরাপত্তা নিয়মে নিম্নলিখিত query. এক্সপ্রেশন উপলভ্য।

কোয়েরি-ভিত্তিক রুল এক্সপ্রেশন
এক্সপ্রেশন Type বিবরণ
query.orderByKey
query.orderByPriority
query.orderByValue		 বুলিয়ান কী, অগ্রাধিকার বা ভ্যালু অনুযায়ী সাজানো কোয়েরির ক্ষেত্রে সত্য। তা না হলে, সেটি 'ফল্স' বলে গণ্য করা হবে।
query.orderByChild স্ট্রিং
ফাঁকা		 চাইল্ড নোডের রিলেটিভ পাথ দেখানোর জন্য স্ট্রিং ব্যবহার করুন। যেমন, query.orderByChild === "address/zip"। কোয়েরি যদি চাইল্ড নোড দ্বারা অর্ডার করা না হয়, তাহলে এই ভ্যালু নাল হয়।
query.startAt
query.endAt
query.equalTo		 স্ট্রিং
সংখ্যা
বুলিয়ান
ফাঁকা		 এক্সিকিউট করা কোয়েরির বাউন্ড ফিরিয়ে আনে অথবা কোনও বাউন্ড সেট করা না থাকলে নাল ফিরিয়ে আনে।
query.limitToFirst
query.limitToLast		 নম্বর
null		 এক্সিকিউট করা কোয়েরির সীমা ফিরিয়ে আনে অথবা কোনও সীমা সেট করা না থাকলে নাল ফিরিয়ে আনে।

পরবর্তী ধাপ

শর্তাবলী নিয়ে এই আলোচনার পরে, আপনি Security Rules সম্পর্কে আরও ভালভাবে বুঝতে পেরেছেন এবং এগুলি করতে প্রস্তুত:

কীভাবে মূল ব্যবহারের কেসগুলি পরিচালনা করতে হয় তা জানুন এবং ডেভেলপ, পরীক্ষা এবং ডিপ্লয় করার জন্য ওয়ার্কফ্লো জানুন Security Rules:

Realtime Database-এর জন্য নির্দিষ্ট Security Rules ফিচার সম্পর্কে জানুন: