কিভাবে আপনার Firebase রিয়েলটাইম ডেটাবেস নিরাপত্তা নিয়মে শর্ত যোগ করতে হয় তা দেখানোর জন্য এই গাইডটি মূল ফায়ারবেস নিরাপত্তা বিধি ভাষা নির্দেশিকা শিখতে তৈরি করে।
রিয়েলটাইম ডেটাবেস নিরাপত্তা নিয়মের প্রাথমিক বিল্ডিং ব্লক হল শর্ত । একটি শর্ত হল একটি বুলিয়ান অভিব্যক্তি যা নির্ধারণ করে যে একটি নির্দিষ্ট অপারেশন অনুমোদিত বা অস্বীকার করা উচিত। মৌলিক নিয়মের জন্য, শর্ত হিসাবে true
এবং false
আক্ষরিক ব্যবহার করে নিখুঁতভাবে কাজ করে। কিন্তু রিয়েলটাইম ডেটাবেস সিকিউরিটি রুলস ল্যাঙ্গুয়েজ আপনাকে আরও জটিল শর্ত লিখতে পারে যা করতে পারে:
- ব্যবহারকারীর প্রমাণীকরণ পরীক্ষা করুন
- নতুন জমা দেওয়া ডেটার বিপরীতে বিদ্যমান ডেটা মূল্যায়ন করুন
- আপনার ডাটাবেসের বিভিন্ন অংশ অ্যাক্সেস করুন এবং তুলনা করুন
- ইনকামিং ডেটা যাচাই করুন
- নিরাপত্তা যুক্তির জন্য ইনকামিং প্রশ্নের গঠন ব্যবহার করুন
পাথ সেগমেন্ট ক্যাপচার করতে $ ভেরিয়েবল ব্যবহার করে
আপনি $
উপসর্গের সাথে ক্যাপচার ভেরিয়েবল ঘোষণা করে পাঠ বা লেখার জন্য পাথের অংশগুলি ক্যাপচার করতে পারেন। এটি একটি ওয়াইল্ড কার্ড হিসাবে কাজ করে এবং নিয়মের শর্তগুলির মধ্যে ব্যবহারের জন্য সেই কীটির মান সংরক্ষণ করে:
{ "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')" } } } } }
গতিশীল $
ভেরিয়েবলগুলি ধ্রুবক পাথ নামের সাথে সমান্তরালভাবে ব্যবহার করা যেতে পারে। এই উদাহরণে, আমরা একটি .validate
নিয়ম ঘোষণা করতে $other
ভেরিয়েবল ব্যবহার করছি যা নিশ্চিত করে যে 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 প্রমাণীকরণ ব্যবহার করে, request.auth
ভেরিয়েবলে ক্লায়েন্টের অনুরোধ করা ডেটার প্রমাণীকরণ তথ্য থাকে। request.auth
সম্পর্কে আরও তথ্যের জন্য, রেফারেন্স ডকুমেন্টেশন দেখুন।
Firebase Authentication Firebase Realtime Database সাথে একীভূত হয় যাতে আপনি শর্তগুলি ব্যবহার করে প্রতি-ব্যবহারকারীর ভিত্তিতে ডেটা অ্যাক্সেস নিয়ন্ত্রণ করতে পারেন। একবার একজন ব্যবহারকারী প্রমাণীকরণ করলে, আপনার রিয়েলটাইম ডেটাবেস সিকিউরিটি রুলসের auth
ভেরিয়েবল ব্যবহারকারীর তথ্য দ্বারা পপুলেট করা হবে। এই তথ্যের মধ্যে রয়েছে তাদের অনন্য শনাক্তকারী ( uid
) পাশাপাশি লিঙ্ক করা অ্যাকাউন্ট ডেটা, যেমন Facebook id বা একটি ইমেল ঠিকানা এবং অন্যান্য তথ্য। আপনি যদি একটি কাস্টম প্রমাণীকরণ প্রদানকারী প্রয়োগ করেন, তাহলে আপনি আপনার ব্যবহারকারীর প্রমাণীকরণ পেলোডে আপনার নিজস্ব ক্ষেত্র যোগ করতে পারেন৷
এই বিভাগটি ব্যাখ্যা করে যে কীভাবে আপনার ব্যবহারকারীদের সম্পর্কে প্রমাণীকরণ তথ্যের সাথে ফায়ারবেস রিয়েলটাইম ডেটাবেস নিরাপত্তা নিয়মের ভাষা একত্রিত করা যায়। এই দুটি ধারণাকে একত্রিত করে, আপনি ব্যবহারকারীর পরিচয়ের উপর ভিত্তি করে ডেটা অ্যাক্সেস নিয়ন্ত্রণ করতে পারেন।
auth
পরিবর্তনশীল
প্রমাণীকরণ সঞ্চালিত হওয়ার আগে নিয়মে পূর্বনির্ধারিত auth
পরিবর্তনশীলটি শূন্য।
একবার একজন ব্যবহারকারী ফায়ারবেস প্রমাণীকরণের সাথে প্রমাণীকরণ করা হলে এতে নিম্নলিখিত বৈশিষ্ট্যগুলি থাকবে:
প্রদানকারী | ব্যবহৃত প্রমাণীকরণ পদ্ধতি ("পাসওয়ার্ড", "বেনামী", "ফেসবুক", "গিথুব", "গুগল", বা "টুইটার")। |
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" } } } }
প্রমাণীকরণ শর্ত সমর্থন করার জন্য আপনার ডাটাবেস গঠন
এটি সাধারণত আপনার ডাটাবেসকে এমনভাবে গঠন করা সহায়ক যা Rules লেখা সহজ করে তোলে। Realtime Database ব্যবহারকারীর ডেটা সংরক্ষণের জন্য একটি সাধারণ প্যাটার্ন হল আপনার সমস্ত ব্যবহারকারীকে একটি একক users
নোডে সংরক্ষণ করা যার শিশু প্রতিটি ব্যবহারকারীর জন্য uid
মান। আপনি যদি এই ডেটাতে অ্যাক্সেস সীমাবদ্ধ করতে চান যাতে শুধুমাত্র লগ-ইন করা ব্যবহারকারীরা তাদের নিজস্ব ডেটা দেখতে পারে, আপনার নিয়মগুলি এরকম কিছু দেখাবে৷
{ "rules": { "users": { "$uid": { ".read": "auth !== null && auth.uid === $uid" } } } }
প্রমাণীকরণ কাস্টম দাবি নিয়ে কাজ করা
বিভিন্ন ব্যবহারকারীর জন্য কাস্টম অ্যাক্সেস নিয়ন্ত্রণ প্রয়োজন এমন অ্যাপগুলির জন্য, 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 বিন্যাসে 1900-2099 সালের মধ্যে তারিখগুলিকে অনুমতি দেয়, যা একটি নিয়মিত অভিব্যক্তি ব্যবহার করে চেক করা হয়৷
".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
)।
এগুলি তুচ্ছ পয়েন্টের মতো মনে হতে পারে, কিন্তু প্রকৃতপক্ষে শক্তিশালী ফায়ারবেস রিয়েলটাইম ডেটাবেস নিরাপত্তা নিয়ম লেখার জন্য উল্লেখযোগ্য বৈশিষ্ট্য। নিম্নলিখিত নিয়ম বিবেচনা করুন:
{ "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);
উদ্দেশ্য-C
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];
সুইফট
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);
বিশ্রাম
# 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);
উদ্দেশ্য-C
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];
সুইফট
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);
বিশ্রাম
# 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
পঠিত ক্রিয়াকলাপগুলির মাধ্যমে একজন ক্লায়েন্ট কত ডেটা ডাউনলোড করবে তা সীমাবদ্ধ করতে আপনি ক্যোয়ারী-ভিত্তিক নিয়মগুলিও ব্যবহার করতে পারেন।
উদাহরণ স্বরূপ, নিম্নোক্ত নিয়মটি অগ্রাধিকার দ্বারা আদেশ অনুসারে একটি প্রশ্নের প্রথম 1000টি ফলাফলে পড়ার অ্যাক্সেসকে সীমাবদ্ধ করে:
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.
এক্সপ্রেশন রিয়েলটাইম ডাটাবেস নিরাপত্তা নিয়ম উপলব্ধ.
প্রশ্ন-ভিত্তিক নিয়মের অভিব্যক্তি | ||
---|---|---|
অভিব্যক্তি | টাইপ | বর্ণনা |
query.orderByKey query.orderByPriority query.orderByValue | বুলিয়ান | কী, অগ্রাধিকার বা মান দ্বারা আদেশ করা প্রশ্নের জন্য সত্য। অন্যথায় মিথ্যা। |
query.orderByChild | স্ট্রিং নাল | একটি চাইল্ড নোডের আপেক্ষিক পথ উপস্থাপন করতে একটি স্ট্রিং ব্যবহার করুন। উদাহরণস্বরূপ, query.orderByChild === "address/zip" । যদি কোয়েরি একটি চাইল্ড নোড দ্বারা আদেশ না করা হয়, তাহলে এই মানটি শূন্য। |
query.startAt query.endAt query.equalTo | স্ট্রিং সংখ্যা বুলিয়ান নাল | এক্সিকিউটিং কোয়েরির সীমানা পুনরুদ্ধার করে, অথবা কোনো আবদ্ধ সেট না থাকলে শূন্য ফেরত দেয়। |
query.limitToFirst query.limitToLast | সংখ্যা নাল | এক্সিকিউটিং ক্যোয়ারীতে সীমা পুনরুদ্ধার করে, অথবা সীমা সেট না থাকলে শূন্য প্রদান করে। |
পরবর্তী পদক্ষেপ
শর্তগুলির এই আলোচনার পরে, আপনি Rules আরও পরিশীলিত উপলব্ধি পেয়েছেন এবং এর জন্য প্রস্তুত:
মূল ব্যবহারের ক্ষেত্রে কীভাবে পরিচালনা করতে হয় তা শিখুন এবং Rules তৈরি, পরীক্ষা এবং স্থাপনের জন্য কর্মপ্রবাহ শিখুন:
- আপনি শর্ত তৈরি করতে ব্যবহার করতে পারেন এমন পূর্বনির্ধারিত Rules ভেরিয়েবলের সম্পূর্ণ সেট সম্পর্কে জানুন।
- নিয়মগুলি লিখুন যা সাধারণ পরিস্থিতিগুলিকে সম্বোধন করে।
- এমন পরিস্থিতি পর্যালোচনা করে আপনার জ্ঞান গড়ে তুলুন যেখানে আপনাকে অবশ্যই অনিরাপদ নিয়মগুলি চিহ্নিত করতে হবে এবং এড়াতে হবে ৷
- ফায়ারবেস স্থানীয় এমুলেটর স্যুট সম্পর্কে জানুন এবং Rules পরীক্ষা করতে আপনি কীভাবে এটি ব্যবহার করতে পারেন।
- Rules স্থাপনের জন্য উপলব্ধ পদ্ধতিগুলি পর্যালোচনা করুন৷
Realtime Database জন্য নির্দিষ্ট Rules বৈশিষ্ট্যগুলি জানুন:
- আপনার Realtime Database কীভাবে সূচী করতে হয় তা জানুন।
- Rules স্থাপনের জন্য REST API পর্যালোচনা করুন।