रीयलटाइम डेटाबेस नियम भाषा के मूल सिंटैक्स को जानें

फायरबेस रीयलटाइम डेटाबेस सुरक्षा नियम आपको अपने डेटाबेस में संग्रहीत डेटा तक पहुंच को नियंत्रित करने की अनुमति देते हैं। लचीला नियम सिंटैक्स आपको ऐसे नियम बनाने की अनुमति देता है जो किसी भी चीज़ से मेल खाते हैं, आपके डेटाबेस में लिखने से लेकर अलग-अलग नोड्स पर संचालन तक।

रीयलटाइम डाटाबेस सुरक्षा नियम अपने डेटाबेस के लिए घोषणात्मक विन्यास कर रहे हैं। इसका मतलब है कि नियमों को उत्पाद तर्क से अलग परिभाषित किया गया है। इसके कई फायदे हैं: क्लाइंट सुरक्षा लागू करने के लिए ज़िम्मेदार नहीं हैं, बग्गी कार्यान्वयन आपके डेटा से समझौता नहीं करेगा, और शायद सबसे महत्वपूर्ण बात यह है कि दुनिया से डेटा की सुरक्षा के लिए सर्वर जैसे मध्यवर्ती रेफरी की कोई आवश्यकता नहीं है।

यह विषय मूल सिंटैक्स और संरचना रीयलटाइम डेटाबेस सुरक्षा नियमों का वर्णन करता है जिनका उपयोग संपूर्ण नियम सेट बनाने के लिए किया जाता है।

अपने सुरक्षा नियमों की संरचना करना

रीयलटाइम डेटाबेस सुरक्षा नियम JSON दस्तावेज़ में शामिल JavaScript जैसे भावों से बने होते हैं। आपके नियमों की संरचना को आपके डेटाबेस में संग्रहीत डेटा की संरचना का पालन करना चाहिए।

बुनियादी नियम का उपयोग तरीकों (जैसे, पढ़ने, लिखने) शामिल है, और शर्तों के तहत पहुँच भी अनुमति या इनकार किया है की पहचान, नोड्स का एक सेट सुरक्षित करने की। निम्न उदाहरण में, हमारे शर्तों सरल हो जाएगा true और false बयान है, लेकिन अगले विषय में हम स्थिति को व्यक्त करने के लिए और अधिक गतिशील तरीकों को कवर किया जाएगा।

तो, उदाहरण के लिए, अगर हम एक सुरक्षित करने के लिए कोशिश कर रहे हैं child_node एक के तहत parent_node , पालन करने के लिए सामान्य वाक्य रचना है:

{
  "rules": {
    "parent_node": {
      "child_node": {
        ".read": <condition>,
        ".write": <condition>,
        ".validate": <condition>,
      }
    }
  }
}

आइए इस पैटर्न को लागू करें। उदाहरण के लिए, मान लें कि आप संदेशों की सूची का ट्रैक रख रहे हैं और आपके पास ऐसा डेटा है:

{
  "messages": {
    "message0": {
      "content": "Hello",
      "timestamp": 1405704370369
    },
    "message1": {
      "content": "Goodbye",
      "timestamp": 1405704395231
    },
    ...
  }
}

आपके नियमों को इसी तरह से संरचित किया जाना चाहिए। यहां केवल-पढ़ने के लिए सुरक्षा के नियमों का एक सेट है जो इस डेटा संरचना के लिए उपयोगी हो सकता है। यह उदाहरण दिखाता है कि हम डेटाबेस नोड्स को कैसे निर्दिष्ट करते हैं जिन पर नियम लागू होते हैं और उन नोड्स पर नियमों के मूल्यांकन के लिए शर्तें।

{
  "rules": {
    // For requests to access the 'messages' node...
    "messages": {
      // ...and the individual wildcarded 'message' nodes beneath
      // (we'll cover wildcarding variables more a bit later)....
      "$message": {

        // For each message, allow a read operation if <condition>. In this
        // case, we specify our condition as "true", so read access is always granted.
        ".read": "true",

        // For read-only behavior, we specify that for write operations, our
        // condition is false.
        ".write": "false"
      }
    }
  }
}

बुनियादी नियम संचालन

: वहाँ आपरेशन के प्रकार के आधार पर सुरक्षा लागू करने के लिए नियम के तीन प्रकार डेटा पर प्रदर्शन किया जा रहा है .write , .read , और .validate । यहां उनके उद्देश्यों का त्वरित सारांश दिया गया है:

नियम प्रकार
।पढ़ना वर्णन करता है कि क्या और कब उपयोगकर्ताओं द्वारा डेटा को पढ़ने की अनुमति है।
।लिखो वर्णन करता है कि क्या और कब डेटा लिखने की अनुमति है।
मान्य करें परिभाषित करता है कि सही ढंग से स्वरूपित मान कैसा दिखेगा, क्या इसमें चाइल्ड एट्रिब्यूट और डेटा प्रकार है।

वाइल्डकार्ड कैप्चर वैरिएबल

सभी नियम कथन नोड्स को इंगित करते हैं। एक बयान में एक विशिष्ट नोड को इंगित या उपयोग कर सकते हैं $ पदानुक्रम के स्तर पर नोड्स के सेट करने के लिए बात करने के लिए वाइल्डकार्ड कब्जा चर। बाद के नियमों के बयानों के अंदर उपयोग के लिए नोड कुंजियों के मूल्य को संग्रहीत करने के लिए इन कैप्चर चर का उपयोग करें। इस तकनीक को आप, और अधिक जटिल नियम शर्तों बारे में कुछ हम अगले विषय में अधिक विस्तार से कवर करेंगे देता है।

{
  "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 }
    }
  }
}

नियम पढ़ें और लिखें कैस्केड

.read और .write नियम गहरी नियम अधिभावी उथले नियमों के साथ, ऊपर से नीचे से काम करते हैं। एक नियम के अनुदान एक विशेष मार्ग पर पढ़ सकते हैं या लिखने की अनुमति है, तो यह भी पहुँच इसके तहत सभी बच्चे नोड्स देता है। निम्नलिखित संरचना पर विचार करें:

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          /* ignored, since read was allowed already */
          ".read": false
        }
     }
  }
}

इस सुरक्षा संरचना की अनुमति देता है /bar/ जब भी से पढ़ने के लिए /foo/ एक बच्चे शामिल baz मूल्य के साथ true".read": false तहत नियम /foo/bar/ के बाद से पहुँच एक बच्चे पथ द्वारा रद्द नहीं किया जा सकता कोई प्रभाव नहीं यहाँ, है।

हालांकि यह तुरंत सहज ज्ञान युक्त नहीं लग सकता है, यह नियम भाषा का एक शक्तिशाली हिस्सा है और न्यूनतम प्रयास के साथ बहुत जटिल पहुंच विशेषाधिकारों को लागू करने की अनुमति देता है। इसका वर्णन तब किया जाएगा जब हम इस गाइड में बाद में उपयोगकर्ता-आधारित सुरक्षा में शामिल होंगे।

ध्यान दें कि .validate नियम झरना नहीं है। लिखने की अनुमति के लिए सभी मान्य नियमों को पदानुक्रम के सभी स्तरों पर संतुष्ट होना चाहिए।

नियम फिल्टर नहीं हैं

नियम परमाणु तरीके से लागू होते हैं। इसका अर्थ है कि यदि उस स्थान पर या किसी मूल स्थान पर पहुँच प्रदान करने वाला कोई नियम नहीं है, तो पढ़ने या लिखने का कार्य तुरंत विफल हो जाता है। भले ही हर प्रभावित चाइल्ड पथ पहुंच योग्य हो, मूल स्थान पर पढ़ना पूरी तरह से विफल हो जाएगा। इस संरचना पर विचार करें:

{
  "rules": {
    "records": {
      "rec1": {
        ".read": true
      },
      "rec2": {
        ".read": false
      }
    }
  }
}

समझ है कि नियमों atomically मूल्यांकन किया जाता है के बिना, यह प्राप्त करने में कठिनाई की तरह लग सकता है /records/ पथ वापसी होगी rec1 नहीं बल्कि rec2 । हालाँकि, वास्तविक परिणाम एक त्रुटि है:

जावास्क्रिप्ट
var db = firebase.database();
db.ref("records").once("value", function(snap) {
  // success method is not called
}, function(err) {
  // error callback triggered with PERMISSION_DENIED
});
उद्देश्य सी
नोट: यह Firebase उत्पाद अनुप्रयोग क्लिप लक्ष्य पर उपलब्ध नहीं है।
FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[_ref child:@"records"] observeSingleEventOfType:FIRDataEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
  // success block is not called
} withCancelBlock:^(NSError * _Nonnull error) {
  // cancel block triggered with PERMISSION_DENIED
}];
तीव्र
नोट: यह Firebase उत्पाद अनुप्रयोग क्लिप लक्ष्य पर उपलब्ध नहीं है।
var ref = FIRDatabase.database().reference()
ref.child("records").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // success block is not called
}, withCancelBlock: { error in
    // cancel block triggered with PERMISSION_DENIED
})
जावा
FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // success method is not called
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback triggered with PERMISSION_DENIED
  });
});
विश्राम
curl https://docs-examples.firebaseio.com/rest/records/
# response returns a PERMISSION_DENIED error

पर पढ़ने के आपरेशन के बाद से /records/ परमाणु है, और कोई पढ़ने नियम यह है कि के अंतर्गत सभी डेटा को एक्सेस प्रदान करता है /records/ , यह एक फेंक होगा PERMISSION_DENIED त्रुटि। हम अपने में सुरक्षा सिम्युलेटर में इस नियम का मूल्यांकन तो Firebase कंसोल , हम देख सकते हैं कि पढ़ने के आपरेशन क्योंकि कोई पढ़ने शासन के लिए उपयोग की अनुमति दी मना कर दिया था /records/ पथ। हालांकि, ध्यान दें कि के लिए नियम rec1 का मूल्यांकन नहीं किया गया है क्योंकि यह नहीं पथ हम अनुरोध में था। लाने के लिए rec1 , हम सीधे इसे उपयोग करने की आवश्यकता होगी:

जावास्क्रिप्ट
var db = firebase.database();
db.ref("records/rec1").once("value", function(snap) {
  // SUCCESS!
}, function(err) {
  // error callback is not called
});
उद्देश्य सी
नोट: यह Firebase उत्पाद अनुप्रयोग क्लिप लक्ष्य पर उपलब्ध नहीं है।
FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];
तीव्र
नोट: यह Firebase उत्पाद अनुप्रयोग क्लिप लक्ष्य पर उपलब्ध नहीं है।
var ref = FIRDatabase.database().reference()
ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // SUCCESS!
})
जावा
FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records/rec1");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // SUCCESS!
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback is not called
  }
});
विश्राम
curl https://docs-examples.firebaseio.com/rest/records/rec1
# SUCCESS!

अतिव्यापी कथन

एक नोड पर एक से अधिक नियम लागू करना संभव है। इस मामले में जहां एक से अधिक नियम भाव एक नोड की पहचान में, अभिगम विधि से इनकार किया यदि कोई भी शर्त है false :

{
  "rules": {
    "messages": {
      // A rule expression that applies to all nodes in the 'messages' node
      "$message": {
        ".read": "true",
        ".write": "true"
      },
      // A second rule expression applying specifically to the 'message1` node
      "message1": {
        ".read": "false",
        ".write": "false"
      }
    }
  }
}

उपरोक्त उदाहरण में, करने के लिए पढ़ता है message1 नोड मना कर दिया जाएगा दूसरा नियम हमेशा है, क्योंकि false , भले ही पहला नियम हमेशा true

अगला कदम

आप Firebase रीयलटाइम डेटाबेस सुरक्षा नियमों के बारे में अपनी समझ को गहरा कर सकते हैं:

  • नियम भाषा, गतिशील का अगला प्रमुख अवधारणा जानें की स्थिति है, जो अपने नियम जांच उपयोगकर्ता प्राधिकरण करते हैं, मौजूदा और आने वाले डेटा की तुलना, आने वाले डेटा को मान्य, ग्राहक से आने वाली क्वेरी की संरचना की जाँच, और अधिक।

  • ठेठ सुरक्षा उपयोग के मामलों की समीक्षा करें और Firebase सुरक्षा नियम परिभाषाओं है कि उन्हें पता