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

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. यहां उनके मकसद के बारे में खास जानकारी दी गई है:

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

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

{
  "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 नहीं. हालांकि, असल नतीजा एक गड़बड़ी है:

var db = firebase.database();
db.ref("records").once("value", function(snap) {
  // success method is not called
}, function(err) {
  // error callback triggered with PERMISSION_DENIED
});

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
}];

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 गड़बड़ी मिलेगी. अगर हम अपने पब्लिकेशन नियम लागू करते हैं, तो हम देख सकते हैं कि रीड ऑपरेशन अस्वीकार कर दिया गया क्योंकि किसी भी पढ़ने के नियम ने /records/ पाथ. हालांकि, ध्यान रखें कि rec1 का नियम का आकलन नहीं किया गया, क्योंकि यह उस पाथ में नहीं था जिसके लिए हमने अनुरोध किया था. फ़ेच करने के लिए rec1, हमें इसे सीधे ऐक्सेस करना होगा:

var db = firebase.database();
db.ref("records/rec1").once("value", function(snap) {
  // SUCCESS!
}, function(err) {
  // error callback is not called
});

FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];

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 सुरक्षा नियमों की उन परिभाषाओं को देखें जो उन्हें हल करती हैं.