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

अपना ऐप्लिकेशन बनाते समय, हो सकता है कि आप Cloud Firestore डेटाबेस. हालांकि, ऐप्लिकेशन लॉन्च करने से पहले, आपको बारीकियां देखने की ज़रूरत होगी Cloud Firestore Security Rules. प्रोटोटाइपिंग के अलावा, Cloud Firestore एम्युलेटर के साथ और अपने ऐप्लिकेशन की सामान्य सुविधाओं और व्यवहार की जांच करना, आपके पास यूनिट टेस्ट लिखने का विकल्प है. इससे Cloud Firestore Security Rules के व्यवहार की जांच की जा सकती है.

ध्यान दें: सर्वर क्लाइंट लाइब्रेरी इन सभी को बायपास करती हैं Cloud Firestore Security Rules और इसके बजाय, इसके ज़रिए पुष्टि करें Google ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल. अगर सर्वर क्लाइंट लाइब्रेरी या REST या RPC एपीआई का इस्तेमाल किया जा रहा है, तो पक्का करें कि सेट अप करने के लिए Cloud Firestore की पहचान और ऐक्सेस मैनेजमेंट (आईएएम).

क्विकस्टार्ट

आसान नियमों वाले कुछ बुनियादी टेस्ट केस के लिए, क्विकस्टार्ट सैंपल आज़माएं.

Cloud Firestore Security Rules के बारे में जानकारी

Firebase Authentication को लागू करें और बिना सर्वर वाले डिवाइस के लिए Cloud Firestore Security Rules प्रमाणीकरण, प्राधिकरण, और डेटा सत्यापन, जब आप मोबाइल और वेब क्लाइंट लाइब्रेरी पर लागू होती है.

Cloud Firestore Security Rules में दो हिस्से शामिल हैं:

1. match स्टेटमेंट, जो आपके डेटाबेस में मौजूद दस्तावेज़ों की पहचान करता है.
2. एक allow एक्सप्रेशन, जो उन दस्तावेज़ों के ऐक्सेस को कंट्रोल करता है.

Firebase Authentication, उपयोगकर्ताओं की पहचान की पुष्टि करता है क्रेडेंशियल और बुनियादी जानकारी उपयोगकर्ता और भूमिका पर आधारित ऐक्सेस सिस्टम मिलते हैं.

Cloud Firestore मोबाइल/वेब क्लाइंट लाइब्रेरी से किए गए हर डेटाबेस अनुरोध का आकलन, डेटा पढ़ने या उसमें डेटा लिखने से पहले, सुरक्षा से जुड़े आपके नियमों के हिसाब से किया जाता है. अगर नियम किसी भी दिए गए दस्तावेज़ पथ तक पहुंच अस्वीकार करते हैं, तो अनुरोध पूरा नहीं हुआ.

Cloud Firestore Security Rules का इस्तेमाल शुरू करें में जाकर, Cloud Firestore Security Rules के बारे में ज़्यादा जानें.

एम्युलेटर इंस्टॉल करना

Cloud Firestore एम्युलेटर को इंस्टॉल करने के लिए, Firebase सीएलआई का इस्तेमाल करें और नीचे दिए गए निर्देश को चलाएं:

firebase setup:emulators:firestore

एम्युलेटर चलाएं

सबसे पहले, अपनी वर्किंग डायरेक्ट्री में Firebase प्रोजेक्ट शुरू करें. यह है Firebase सीएलआई का इस्तेमाल करने के दौरान, इस्तेमाल करने के लिए सबसे पहले सामान्य चरण लागू होता है.

firebase init

नीचे दिए गए निर्देश का इस्तेमाल करके, एम्युलेटर को शुरू करें. एम्युलेटर चलेगा जब तक कि आप यह प्रक्रिया खत्म न कर दें:

firebase emulators:start --only firestore

कई मामलों में आप एम्युलेटर शुरू करना चाहते हैं, टेस्ट सुइट चलाना चाहते हैं, और फिर बंद करना चाहते हैं टेस्ट करने के बाद, एम्युलेटर को बंद कर दिया जाएगा. emulators:exec निर्देश का इस्तेमाल करके, ऐसा आसानी से किया जा सकता है:

firebase emulators:exec --only firestore "./my-test-script.sh"

शुरू होने पर, एमुलेटर डिफ़ॉल्ट पोर्ट (8080) पर चलने की कोशिश करेगा. आप अपने डिवाइस के "emulators" सेक्शन में बदलाव करके, एम्युलेटर पोर्ट को बदलें firebase.json फ़ाइल:

{
  // ...
  "emulators": {
    "firestore": {
      "port": "YOUR_PORT"
    }
  }
}

एम्युलेटर को चलाने से पहले

एम्युलेटर का इस्तेमाल शुरू करने से पहले, इन बातों का ध्यान रखें:

• शुरुआत में, एमुलेटर आपकी firebase.json फ़ाइल के firestore.rules फ़ील्ड में बताए गए नियम लोड करेगा. यह एक लोकल फ़ाइल है जिसमें आपका Cloud Firestore Security Rules है और उन नियमों को सभी प्रोजेक्ट. यदि आप स्थानीय फ़ाइल पथ उपलब्ध नहीं कराते या loadFirestoreRules तरीका नीचे बताया गया है, एम्युलेटर सभी का इस्तेमाल करता है ओपन रूल वाले प्रोजेक्ट.
• हालांकि ज़्यादातर Firebase SDK टूल सीधे एम्युलेटर के साथ काम करते हैं, सिर्फ़ @firebase/rules-unit-testing लाइब्रेरी सुरक्षा नियमों में auth का मज़ाक़ बना रहे हैं, जिससे यूनिट टेस्ट बहुत आसान हो जाता है. इसके अलावा, यह लाइब्रेरी, एमुलेटर से जुड़ी कुछ सुविधाओं के साथ काम करती है. जैसे, सारा डेटा मिटाना. इन सुविधाओं के बारे में नीचे बताया गया है.
• एम्युलेटर, प्रोडक्शन में Firebase की पुष्टि करने वाले टोकन भी स्वीकार करेंगे साथ ही, क्लाइंट SDK टूल का इस्तेमाल करके नियमों का आकलन करें, ताकि का इस्तेमाल, सीधे इंटिग्रेशन और मैन्युअल टेस्ट में मौजूद एम्युलेटर पर करने के लिए किया जा सकता है.

लोकल यूनिट टेस्ट चलाना

v9 JavaScript SDK टूल की मदद से लोकल यूनिट टेस्ट करना

Firebase, अपने दोनों वर्शन के साथ सुरक्षा नियमों की यूनिट टेस्टिंग लाइब्रेरी उपलब्ध कराता है 9 JavaScript SDK टूल और उसका 8 वर्शन. लाइब्रेरी एपीआई काफ़ी अलग होते हैं. हमारा सुझाव है कि आप v9 टेस्टिंग लाइब्रेरी का इस्तेमाल करें. यह लाइब्रेरी ज़्यादा बेहतर है और एमुलेटर से कनेक्ट करने के लिए, इसे कम सेटअप करना पड़ता है. इससे, प्रोडक्शन संसाधनों का गलती से इस्तेमाल होने से बचा जा सकता है. पुराने सिस्टम के साथ काम करने की सुविधा के लिए, हम लगातार अपने v8 टेस्टिंग लाइब्रेरी उपलब्ध है.

• v9 SDK टूल में, जांच करने के सामान्य तरीके और यूटिलिटी फ़ंक्शन
• v9 SDK टूल में, एम्युलेटर के हिसाब से बने टेस्ट के तरीके

एम्युलेटर के साथ इंटरैक्ट करने के लिए, @firebase/rules-unit-testing मॉड्यूल का इस्तेमाल करें जो डिवाइस में मौजूद हैं. अगर टाइम आउट या ECONNREFUSED गड़बड़ियां मिलती हैं, तो दोबारा जांच करें है कि एम्युलेटर असल में चल रहा है.

हम Node.js के नए वर्शन का इस्तेमाल करने का सुझाव देते हैं, ताकि आप async/await नोटेशन. आपको जिन गतिविधियों की जांच करनी है उनमें से ज़्यादातर में एसिंक्रोनस फ़ंक्शन शामिल होते हैं. साथ ही, टेस्टिंग मॉड्यूल को प्रॉमिस पर आधारित कोड के साथ काम करने के लिए डिज़ाइन किया गया है.

v9 रूल यूनिट की टेस्टिंग लाइब्रेरी को एम्युलेटर के बारे में हमेशा जानकारी रहती है और कभी भी ऐसा नहीं होता इसके अलावा, प्रोडक्शन से जुड़े संसाधनों को भी बेहतर बनाया जा सकता है.

आप v9 मॉड्यूलर इंपोर्ट स्टेटमेंट का इस्तेमाल करके लाइब्रेरी इंपोर्ट करते हैं. उदाहरण के लिए:

import {
  assertFails,
  assertSucceeds,
  initializeTestEnvironment
} from "@firebase/rules-unit-testing"

// Use `const { … } = require("@firebase/rules-unit-testing")` if imports are not supported
// Or we suggest `const testing = require("@firebase/rules-unit-testing")` if necessary.

इंपोर्ट होने के बाद, यूनिट टेस्ट लागू करने के लिए ये काम करने की ज़रूरत होती है:

• RulesTestEnvironment को बनाया और कॉन्फ़िगर किया जा रहा है. initializeTestEnvironment.
• आसान सुविधा का इस्तेमाल करके, नियमों को ट्रिगर किए बिना टेस्ट डेटा सेट अप करना तरीका है, जिसकी मदद से कुछ समय के लिए इसे बायपास किया जा सकता है, RulesTestEnvironment.withSecurityRulesDisabled.
• हुक से पहले/बाद में टेस्ट सुइट और हर टेस्ट को सेट अप किया जा रहा है. टेस्ट डेटा और एनवायरमेंट को खाली करें, जैसे कि RulesTestEnvironment.cleanup() या RulesTestEnvironment.clearFirestore().
• ऐसे टेस्ट केस लागू करना जो RulesTestEnvironment.authenticatedContext और RulesTestEnvironment.unauthenticatedContext का इस्तेमाल करके, पुष्टि की स्थितियों की नकल करते हैं.

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

सामान्य तरीके और उपयोगिता फ़ंक्शन

SDK टूल के वर्शन 9 में, एमुलेटर के हिसाब से टेस्ट करने के तरीके भी देखें.

initializeTestEnvironment() => RulesTestEnvironment

यह फ़ंक्शन, नियमों की यूनिट की जांच करने के लिए, टेस्ट एनवायरमेंट को शुरू करता है. इसे कॉल करें पहले फ़ंक्शन का इस्तेमाल करें. सफल एक्ज़ीक्यूशन के लिए यह ज़रूरी है कि एम्युलेटर दौड़ने.

यह फ़ंक्शन, TestEnvironmentConfig के बारे में बताने वाले वैकल्पिक ऑब्जेक्ट को स्वीकार करता है, इसमें एक प्रोजेक्ट आईडी और एम्युलेटर कॉन्फ़िगरेशन की सेटिंग शामिल हो सकती हैं.

let testEnv = await initializeTestEnvironment({
  projectId: "demo-project-1234",
  firestore: {
    rules: fs.readFileSync("firestore.rules", "utf8"),
  },
});

ध्यान दें: एम्युलेटर, टेस्ट शुरू करने के बीच डेटा सेव रखते हैं का इस्तेमाल किया जा सकता है. इससे आपके नतीजों पर असर पड़ सकता है. डेटा मिटाने के लिए हर टेस्ट रन के दौरान, लागू होने वाले सटीक एम्युलेटर डेटा मेथड को कॉल करें, उदाहरण के लिए clearFirestoreData, टेस्ट के बीच.

RulesTestEnvironment.authenticatedContext({ user_id: string, tokenOptions?: TokenOptions }) => RulesTestContext

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

कॉन्फ़िगर किए गए किसी भी एमुलेटर इंस्टेंस को ऐक्सेस करने के लिए, अपने टेस्ट में दिखाए गए टेस्ट कॉन्टेक्स्ट ऑब्जेक्ट का इस्तेमाल करें. इनमें initializeTestEnvironment के साथ कॉन्फ़िगर किए गए इंस्टेंस भी शामिल हैं.

// Assuming a Firestore app and the Firestore emulator for this example
import { setDoc } from "firebase/firestore";

const alice = testEnv.authenticatedContext("alice", { … });
// Use the Firestore instance associated with this context
await assertSucceeds(setDoc(alice.firestore(), '/users/alice'), { ... });

RulesTestEnvironment.unauthenticatedContext() => RulesTestContext

इस तरीके से एक RulesTestContext बनता है, जो इस तरह काम करता है: प्रमाणीकरण के ज़रिए लॉग इन नहीं किया है. रिटर्न किए गए कॉन्टेक्स्ट के ज़रिए किए गए अनुरोध Firebase पुष्टि टोकन अटैच होना चाहिए.

किसी भी एम्युलेटर को ऐक्सेस करने के लिए, अपने टेस्ट में टेस्ट के लिए दिखाए गए कॉन्टेक्स्ट ऑब्जेक्ट का इस्तेमाल करें initializeTestEnvironment के साथ कॉन्फ़िगर किए गए इंस्टेंस भी शामिल हैं.

// Assuming a Cloud Storage app and the Storage emulator for this example
import { getStorage, ref, deleteObject } from "firebase/storage";

const alice = testEnv.unauthenticatedContext();

// Use the Cloud Storage instance associated with this context
const desertRef = ref(alice.storage(), 'images/desert.jpg');
await assertSucceeds(deleteObject(desertRef));

RulesTestEnvironment.withSecurityRulesDisabled()

कॉन्टेक्स्ट के साथ टेस्ट सेटअप फ़ंक्शन चलाएं जो इस तरह काम करता है जैसे सुरक्षा के नियम बंद किया गया.

यह तरीका एक कॉलबैक फ़ंक्शन लेता है, जो Security-Rules-bypassing context लेता है और एक प्रॉमिस दिखाता है. प्रॉमिसिंग के बाद कॉन्टेक्स्ट खत्म हो जाएगा समाधान करता है / अस्वीकार करता है.

RulesTestEnvironment.cleanup()

यह तरीका, टेस्टिंग एनवायरमेंट में बनाए गए सभी RulesTestContexts को मिटा देता है और मौजूदा संसाधनों को हटा देता है. इससे, टेस्टिंग से बाहर निकलने में आसानी होती है.

इस तरीके से एम्युलेटर की स्थिति में किसी तरह का बदलाव नहीं होता. टेस्ट के बीच डेटा रीसेट करने के लिए, ऐप्लिकेशन एम्युलेटर के हिसाब से डेटा मिटाने का तरीका अपनाएं.

assertSucceeds(pr: Promise<any>)) => Promise<any>

यह एक टेस्ट केस यूटिलिटी फ़ंक्शन है.

फ़ंक्शन यह पुष्टि करता है कि दिए गए प्रॉमिस में, एम्युलेटर ऑपरेशन को रैप किया गया है सुरक्षा नियम के किसी भी उल्लंघन के बिना हल कर दिया जाएगा.

await assertSucceeds(setDoc(alice.firestore(), '/users/alice'), { ... });

assertFails(pr: Promise<any>)) => Promise<any>

यह एक टेस्ट केस यूटिलिटी फ़ंक्शन है.

यह फ़ंक्शन यह दावा करता है कि एमुलेटर ऑपरेशन को रैप करने वाले प्रॉमिस को, सुरक्षा नियमों के उल्लंघन की वजह से अस्वीकार कर दिया जाएगा.

await assertFails(setDoc(alice.firestore(), '/users/bob'), { ... });

एम्युलेटर के लिए खास तरीके

SDK टूल के v9 वर्शन में, टेस्ट करने के सामान्य तरीके और काम के फ़ंक्शन भी देखें.

RulesTestEnvironment.clearFirestore() => Promise<void>

इस तरीके से, Firestore डेटाबेस में वह डेटा मिट जाता है जो projectId को Firestore एम्युलेटर के लिए कॉन्फ़िगर किया गया.

RulesTestContext.firestore(settings?: Firestore.FirestoreSettings) => Firestore;

जांच के इस कॉन्टेक्स्ट के लिए, इस तरीके को Firestore इंस्टेंस मिलता है. दिखाए गए Firebase JS क्लाइंट SDK टूल के इंस्टेंस का इस्तेमाल, क्लाइंट SDK टूल के एपीआई (v9 मॉड्यूलर या v9 के साथ काम करने वाला) के साथ किया जा सकता है.

नियमों के आकलन को विज़ुअलाइज़ करना

Cloud Firestore एमुलेटर की मदद से, एमुलेटर सुइट के यूज़र इंटरफ़ेस (यूआई) में क्लाइंट के अनुरोधों को विज़ुअलाइज़ किया जा सकता है. इसमें Firebase के सुरक्षा नियमों के लिए, आकलन की ट्रैकिंग भी शामिल है.

Firestore > खोलें अनुरोध टैब से, सभी समस्याओं का आकलन किया जा सकता है हर अनुरोध का क्रम तय करें.

टेस्ट रिपोर्ट जनरेट करना

कई तरह की जांच करने के बाद, जांच के दायरे की रिपोर्ट ऐक्सेस की जा सकती हैं. इन रिपोर्ट से पता चलता है कि आपके हर सुरक्षा नियम का आकलन कैसे किया गया.

रिपोर्ट पाने के लिए, एम्युलेटर पर बिना अनुमति के सार्वजनिक किए गए एंडपॉइंट से क्वेरी करें, जबकि अभी यह चालू है. ब्राउज़र-फ़्रेंडली वर्शन के लिए, इस यूआरएल का इस्तेमाल करें:

http://localhost:8080/emulator/v1/projects/<project_id>:ruleCoverage.html

इससे आपके नियम, एक्सप्रेशन और सब-एक्सप्रेशन में बंट जाते हैं. आकलन और मानों की संख्या सहित ज़्यादा जानकारी के लिए माउसओवर वापस किया गया. इस डेटा के रॉ JSON वर्शन के लिए, यह यूआरएल शामिल करें आपकी क्वेरी में:

http://localhost:8080/emulator/v1/projects/<project_id>:ruleCoverage

एम्युलेटर और प्रोडक्शन के बीच अंतर

1. आपको साफ़ तौर पर Cloud Firestore प्रोजेक्ट बनाने की ज़रूरत नहीं है. एम्युलेटर अपने-आप ऐसा कोई भी इंस्टेंस बनाता है जिसे ऐक्सेस किया जाता है.
2. Cloud Firestore एम्युलेटर, सामान्य Firebase Authentication फ़्लो के साथ काम नहीं करता. इसके बजाय, हमने Firebase टेस्ट SDK टूल में initializeTestApp() तरीका उपलब्ध कराया है rules-unit-testing लाइब्रेरी, जिसके लिए auth फ़ील्ड लेना पड़ता है. Firebase हैंडल बनाया गया इस तरीके का इस्तेमाल करने पर, यह इस तरह काम करेगा: को नहीं दिया जाएगा. अगर आप null में पास करते हैं, तो यह इस तरह काम करेगा: उपयोगकर्ता की पुष्टि नहीं हुई है (उदाहरण के लिए, auth != null नियम काम नहीं करेंगे).

आम तौर पर होने वाली समस्याओं को हल करना

Cloud Firestore एम्युलेटर का इस्तेमाल करने पर, आपके पास यहां दी गई समस्याएं. अनियमित व्यवहार की समस्या को हल करने के लिए, नीचे दिए गए दिशा-निर्देशों का पालन करें अनुभव कर रहा है. ये नोट, सुरक्षा नियमों की यूनिट टेस्टिंग की मदद से लिखे गए हैं लाइब्रेरी के लिए भी बनाया गया है, लेकिन किसी भी Firebase SDK टूल पर ये सामान्य तरीके लागू किए जा सकते हैं.

जांच करने का तरीका अलग-अलग है

अगर आपके टेस्ट कभी-कभी पास और कभी-कभी फ़ेल होते हैं, तो हो सकता है कि टेस्ट में कोई बदलाव किए बिना भी ऐसा हो. ऐसे में, आपको यह पुष्टि करनी होगी कि टेस्ट का क्रम सही है या नहीं. एम्युलेटर के साथ होने वाले ज़्यादातर इंटरैक्शन एसिंक्रोनस होते हैं. इसलिए, पक्का करें कि सभी एक साथ काम नहीं करने वाली प्रोसेस को सही क्रम में लगाया गया है. आप इनमें से किसी एक तरीके से क्रम तय कर सकते हैं वादों को जोड़ने या await नोटेशन का बेझिझक इस्तेमाल करना.

खास तौर पर, ये एक साथ काम नहीं करने वाली प्रोसेस की समीक्षा करें:

• सुरक्षा के नियम सेट करना. जैसे, initializeTestEnvironment.
• डेटा को पढ़ना और लिखना. जैसे, db.collection("users").doc("alice").get().
• कार्रवाइयों से जुड़े दावे, जिनमें assertSucceeds और assertFails शामिल हैं.

एम्युलेटर को पहली बार लोड करने पर ही टेस्ट पास होते हैं

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

• हर जांच के लिए, यूनीक प्रोजेक्ट आईडी का इस्तेमाल करें. ध्यान दें कि अगर आपको ऐसा करना है हर टेस्ट के दौरान, initializeTestEnvironment को कॉल करना होगा; नियम सिर्फ़ डिफ़ॉल्ट प्रोजेक्ट आईडी के लिए अपने-आप लोड होती हैं.
• अपने टेस्ट को फिर से बनाएं, ताकि वे पहले से लिखे गए डेटा के साथ इंटरैक्ट न करें. उदाहरण के लिए, हर टेस्ट के लिए अलग कलेक्शन का इस्तेमाल करें.
• टेस्ट के दौरान लिखा गया सारा डेटा मिटाएं.

टेस्ट सेटअप करना बहुत मुश्किल है

टेस्ट सेट अप करते समय, हो सकता है कि आप डेटा में ऐसे बदलाव करना चाहें जिनकी अनुमति आपके Cloud Firestore Security Rules में न हो. अगर आपके नियम, टेस्ट सेटअप कर रहे हैं जटिल, अपने सेटअप में RulesTestEnvironment.withSecurityRulesDisabled का इस्तेमाल करके देखें चरणों को पूरा करने की कोशिश करता है, इसलिए पढ़ने और लिखने से PERMISSION_DENIED गड़बड़ियां ट्रिगर नहीं होंगी.

इसके बाद, आपका टेस्ट RulesTestEnvironment.authenticatedContext और unauthenticatedContext का इस्तेमाल करके, पुष्टि किए गए या पुष्टि नहीं किए गए उपयोगकर्ता के तौर पर ऑपरेशन कर सकता है. इससे आपको यह पुष्टि करने की सुविधा मिलती है कि आपका Cloud Firestore Security Rules अनुमति देता है / अस्वीकार करता है अलग-अलग मामलों को सही ढंग से दर्ज किया है.