Firebase Security Rules, ऐक्सेस कंट्रोल और डेटा की पुष्टि करने की सुविधा देता है. यह सुविधा, कई लेवल की जटिलता वाले फ़ॉर्मैट में काम करती है. उपयोगकर्ता और भूमिका के आधार पर ऐक्सेस सिस्टम बनाने के लिए, Firebase Authentication का इस्तेमाल Firebase Security Rules के साथ करें. इससे आपके उपयोगकर्ताओं का डेटा सुरक्षित रहेगा.
उपयोगकर्ताओं की पहचान करना
Authentication उन उपयोगकर्ताओं की पहचान करता है जो आपके डेटा को ऐक्सेस करने का अनुरोध करते हैं. साथ ही, उस जानकारी को एक वैरिएबल के तौर पर उपलब्ध कराता है, जिसका इस्तेमाल नियमों में किया जा सकता है. auth
वैरिएबल में यह जानकारी शामिल होती है:
uid
: अनुरोध करने वाले उपयोगकर्ता को असाइन किया गया यूनीक यूज़र आईडी.token
: Authentication से इकट्ठा की गई वैल्यू का मैप.
auth.token
वैरिएबल में ये वैल्यू शामिल होती हैं:
फ़ील्ड | ब्यौरा |
---|---|
email |
अगर खाता मौजूद है, तो उससे जुड़ा ईमेल पता. |
email_verified |
true अगर उपयोगकर्ता ने पुष्टि कर दी है कि उसके पास email पते का ऐक्सेस है. ईमेल की सेवा देने वाली कुछ कंपनियां, अपने ईमेल पतों की पुष्टि अपने-आप कर लेती हैं. |
phone_number |
खाते से जुड़ा फ़ोन नंबर, अगर मौजूद है. |
name |
अगर उपयोगकर्ता का डिसप्ले नेम सेट है, तो यह उसका डिसप्ले नेम होता है. |
sub |
उपयोगकर्ता का Firebase यूआईडी. यह किसी प्रोजेक्ट में यूनीक होता है. |
firebase.identities |
इस उपयोगकर्ता के खाते से जुड़ी सभी पहचानों की डिक्शनरी. डिक्शनरी की कुंजियां इनमें से कोई भी हो सकती हैं: email , phone , google.com , facebook.com , github.com , twitter.com . डिक्शनरी की वैल्यू, खाते से जुड़े हर आइडेंटिटी प्रोवाइडर के लिए यूनीक आइडेंटिफ़ायर के ऐरे होते हैं. उदाहरण के लिए, auth.token.firebase.identities["google.com"][0] में खाते से जुड़ा पहला Google उपयोगकर्ता आईडी होता है. |
firebase.sign_in_provider |
इस टोकन को पाने के लिए, साइन-इन की सुविधा देने वाली कंपनी का इस्तेमाल किया गया था. यह इनमें से कोई भी स्ट्रिंग हो सकती है: custom , password , phone , anonymous , google.com , facebook.com , github.com , twitter.com . |
firebase.tenant |
अगर खाते से tenantId जुड़ा है, तो उसे दिखाता है. उदाहरण के लिए, tenant2-m6tyz |
अगर आपको पसंद के मुताबिक बनाए गए पुष्टि करने वाले एट्रिब्यूट जोड़ने हैं, तो auth.token
वैरिएबल में आपके तय किए गए कस्टम दावे भी शामिल होते हैं.
अगर ऐक्सेस का अनुरोध करने वाला उपयोगकर्ता साइन इन नहीं है, तो auth
वैरिएबल null
होता है.
अगर आपको सिर्फ़ पुष्टि किए गए उपयोगकर्ताओं को पढ़ने का ऐक्सेस देना है, तो इस सुविधा का इस्तेमाल अपने नियमों में किया जा सकता है. उदाहरण के लिए, auth != null
. हालांकि, हमारा सुझाव है कि आप लिखने के ऐक्सेस को और सीमित करें.
auth
वैरिएबल के बारे में ज़्यादा जानने के लिए, Cloud Firestore, Realtime Database, और Cloud Storage के लिए रेफ़रंस दस्तावेज़ देखें.
नियमों में उपयोगकर्ता की जानकारी का इस्तेमाल करना
असल में, पुष्टि की गई जानकारी का इस्तेमाल करने से, आपके नियम ज़्यादा असरदार और सुविधाजनक बन जाते हैं. उपयोगकर्ता की पहचान के आधार पर, डेटा के ऐक्सेस को कंट्रोल किया जा सकता है.
अपने नियमों में यह तय करें कि auth
वैरिएबल में मौजूद जानकारी — यानी कि अनुरोध करने वाले व्यक्ति की जानकारी — अनुरोध किए गए डेटा से जुड़ी उपयोगकर्ता की जानकारी से कैसे मैच करती है.
उदाहरण के लिए, आपका ऐप्लिकेशन यह पक्का करना चाहता है कि उपयोगकर्ता सिर्फ़ अपना डेटा पढ़ और लिख सकें. इस स्थिति में, आपको अनुरोध किए गए डेटा में मौजूद auth.uid
वैरिएबल और User-ID को मैच करना होगा:
Cloud Firestore
service cloud.firestore {
match /databases/{database}/documents {
// Make sure the uid of the requesting user matches name of the user
// document. The wildcard expression {userId} makes the userId variable
// available in rules.
match /users/{userId} {
allow read, write: if request.auth != null && request.auth.uid == userId;
}
}
}
Realtime Database
{
"rules": {
"users": {
"$userId": {
// grants write access to the owner of this user account
// whose uid must exactly match the key ($userId)
".write": "$userId === auth.uid"
}
}
}
}
Cloud Storage
service firebase.storage {
// Only a user can upload their file, but anyone can view it
match /users/{userId}/{fileName} {
allow read;
allow write: if request.auth != null && request.auth.uid == userId;
}
}
उपयोगकर्ता की पसंद के मुताबिक जानकारी तय करना
auth
वैरिएबल का इस्तेमाल करके, अपने ऐप्लिकेशन के उपयोगकर्ताओं को असाइन किए गए कस्टम फ़ील्ड तय किए जा सकते हैं.
उदाहरण के लिए, मान लें कि आपको "एडमिन" भूमिका बनानी है. इससे कुछ पाथ पर लिखने का ऐक्सेस मिलता है. आपको उस एट्रिब्यूट को उपयोगकर्ताओं को असाइन करना होगा. इसके बाद, पाथ पर ऐक्सेस देने वाले नियमों में इसका इस्तेमाल करना होगा.
Cloud Firestore में, उपयोगकर्ताओं के दस्तावेज़ों में कस्टम फ़ील्ड जोड़ा जा सकता है. साथ ही, अपने नियमों में एम्बेड किए गए रीड का इस्तेमाल करके, उस फ़ील्ड की वैल्यू को वापस पाया जा सकता है. इसलिए, एडमिन के आधार पर तय किया गया नियम कुछ ऐसा दिखेगा:
Cloud Firestore
service cloud.firestore {
match /databases/{database}/documents/some_collection: {
// Remember that, in Cloud Firestore, reads embedded in your rules are billed operations
write: if request.auth != null && get(/databases/(database)/documents/users/$(request.auth.uid)).data.admin == true;
read: if request.auth != null;
}
}
Authentication में कस्टम दावे बनाने के बाद, Rules में कस्टम दावों को ऐक्सेस किया जा सकता है. इसके बाद, auth.token
वैरिएबल का इस्तेमाल करके, उन कस्टम दावों को रेफ़र किया जा सकता है.
Cloud Firestore
service cloud.firestore {
match /databases/{database}/documents {
// For attribute-based access control, check for an admin claim
allow write: if request.auth.token.admin == true;
allow read: true;
// Alterntatively, for role-based access, assign specific roles to users
match /some_collection/{document} {
allow read: if request.auth.token.reader == "true";
allow write: if request.auth.token.writer == "true";
}
}
}
Realtime Database
{
"rules": {
"some_path/$sub_path": {
// Create a custom claim for the admin role
".write": "auth.uid !== null && auth.token.writer === true"
".read": "auth.uid !== null"
}
}
}
Cloud Storage
service firebase.storage {
// Create a custom claim for the admin role
match /files/{fileName} {
allow read: if request.auth.uid != null;
allow write: if request.auth.token.admin == true;
}
}
बुनियादी Rules का इस्तेमाल करने के ज़्यादा उदाहरण देखने के लिए, सुरक्षा से जुड़े बुनियादी नियम देखें.Authentication