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

Firebase रीयल टाइम डेटाबेस के सुरक्षा नियमों की मदद से, सेव किए गए डेटा के ऐक्सेस को कंट्रोल किया जा सकता है आपके डेटाबेस में मौजूद है. सुविधाजनक नियमों के सिंटैक्स की मदद से आपके डेटाबेस से लेकर ऑपरेशन तक, किसी भी चीज़ से मेल खाने वाले नियम अलग-अलग नोड पर.

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

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

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

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

बुनियादी नियम, सुरक्षित किए जाने वाले नोड के सेट की पहचान करते हैं, जैसे कि ऐक्सेस के तरीके (जैसे, पढ़ना, लिखें) शामिल है और वे शर्तें जिनके तहत ऐक्सेस दिया जाता है या अस्वीकार किया जाता है. नीचे दिए गए उदाहरणों में, हमारी शर्तें आसान 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. यहां उनके मकसद के बारे में खास जानकारी दी गई है:

नियम के प्रकार
.read इससे यह पता चलता है कि उपयोगकर्ता, डेटा को कब पढ़ सकते हैं.
.लिखें यह बताता है कि डेटा लिखने की अनुमति है या नहीं और कब है.
.verification इससे तय होता है कि सही तरीके से फ़ॉर्मैट की गई वैल्यू कैसी दिखेगी चाइल्ड एट्रिब्यूट और डेटा टाइप मौजूद है.

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

सभी नियम स्टेटमेंट, नोड के बारे में बताते हैं. स्टेटमेंट में नोड के सेट पर पॉइंट करने के लिए, आप $ वाइल्डकार्ड कैप्चर वैरिएबल का इस्तेमाल कर सकते हैं डालें. नोड का मान स्टोर करने के लिए इन कैप्चर वैरिएबल का इस्तेमाल करें की का इस्तेमाल बाद के नियम स्टेटमेंट में करने के लिए किया जाता है. इस तकनीक की मदद से, Rules शर्तें ज़्यादा जटिल होंगी. हम इनके बारे में विस्तार से बताएंगे अगले विषय में.

{
  "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/ में true वैल्यू वाला एक चाइल्ड baz शामिल है. /foo/bar/ के तहत ".read": false नियम में ऐसा नहीं है यहां इफ़ेक्ट लागू होता है, क्योंकि चाइल्ड पाथ से ऐक्सेस को रद्द नहीं किया जा सकता.

ऐसा हो सकता है कि आपको यह तुरंत सहज न लगे, लेकिन यह नियमों की भाषा का एक अहम हिस्सा है और इसके इस्तेमाल से, लोगों के लिए ऐक्सेस के कई जटिल अधिकार आसानी से लागू किए जा सकते हैं. यह को तब दिखाया जाएगा, जब हम इस गाइड में बाद में उपयोगकर्ता-आधारित सुरक्षा के बारे में जानेंगे.

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

नियम फ़िल्टर नहीं होते

नियम, ऐटमिक तरीके से लागू होते हैं. इसका मतलब है कि पढ़ना या लिखना अगर उस जगह या पैरंट लोकेशन, जो ऐक्सेस देता है. भले ही, हर उस चाइल्ड पाथ को ऐक्सेस किया जा सकता हो जिस पर असर पड़ा है, मूल स्थान पर पढ़ना पूरी तरह से विफल हो जाएगा. इस स्ट्रक्चर को ध्यान में रखें:

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

नियमों का मूल्यांकन अपने आप होने वाले तरीके से किए जाने पर, ऐसा लग सकता है कि /records/ पाथ फ़ेच करने पर, rec1 दिखेगा लेकिन rec2 नहीं. हालांकि, असल नतीजा एक गड़बड़ी है:

JavaScript
var db = firebase.database();
db.ref("records").once("value", function(snap) {
  // success method is not called
}, function(err) {
  // error callback triggered with PERMISSION_DENIED
});
Objective-C
ध्यान दें: Firebase का यह प्रॉडक्ट, App Clip के टारगेट पर उपलब्ध नहीं है.
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
}];
Swift
ध्यान दें: Firebase का यह प्रॉडक्ट, App Clip के टारगेट पर उपलब्ध नहीं है.
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
})
Java
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
  });
});
REST
curl https://docs-examples.firebaseio.com/rest/records/
# response returns a PERMISSION_DENIED error

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

JavaScript
var db = firebase.database();
db.ref("records/rec1").once("value", function(snap) {
  // SUCCESS!
}, function(err) {
  // error callback is not called
});
Objective-C
ध्यान दें: Firebase का यह प्रॉडक्ट, App Clip के टारगेट पर उपलब्ध नहीं है.
FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];
Swift
ध्यान दें: Firebase का यह प्रॉडक्ट, App Clip के टारगेट पर उपलब्ध नहीं है.
var ref = FIRDatabase.database().reference()
ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // SUCCESS!
})
Java
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
  }
});
REST
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 रीयल टाइम डेटाबेस के सुरक्षा नियमों को बेहतर तरीके से समझा जा सकता है:

  • Rules भाषा के डाइनैमिक कॉन्सेप्ट का अगला मुख्य सिद्धांत जानें स्थितियां, जिनकी मदद से आपका Rules उपयोगकर्ता की जांच कर सकता है अनुमति देना, मौजूदा और इनकमिंग डेटा की तुलना करना, आने वाले डेटा की पुष्टि करना, जांच करना क्लाइंट से मिलने वाली क्वेरी के स्ट्रक्चर, और भी बहुत कुछ.

  • सुरक्षा के इस्तेमाल के सामान्य उदाहरणों और Firebase सुरक्षा नियमों की उन परिभाषाओं को देखें जो उन्हें हल करती हैं.