অনিরাপদ নিয়ম ঠিক করুন

Cloud Firestore Security Rules কনফিগারেশনের সাধারণ দুর্বলতাগুলি বুঝতে, আপনার নিজস্ব নিয়মগুলি পর্যালোচনা এবং আরও ভালভাবে সুরক্ষিত করতে এবং সেগুলি স্থাপন করার আগে আপনার পরিবর্তনগুলি পরীক্ষা করতে এই নির্দেশিকাটি ব্যবহার করুন।

যদি আপনি একটি সতর্কতা পান যে আপনার Cloud Firestore ডাটাবেস সঠিকভাবে সুরক্ষিত নয়, তাহলে আপনি আপনার Cloud Firestore Security Rules পরিবর্তন এবং পরীক্ষা করে দুর্বলতাগুলি সমাধান করতে পারেন।

আপনার বিদ্যমান নিরাপত্তা নিয়মগুলি দেখতে, Firebase কনসোলের নিয়ম ট্যাবে যান।

আপনার Cloud Firestore Security Rules বুঝুন

Cloud Firestore Security Rules আপনার ডেটা ক্ষতিকারক ব্যবহারকারীদের হাত থেকে রক্ষা করে। Firebase কনসোলে তৈরি যেকোনো Cloud Firestore ইনস্ট্যান্সের ডিফল্ট রুলস সকল ব্যবহারকারীর অ্যাক্সেস অস্বীকার করে। আপনার অ্যাপ ডেভেলপ করতে এবং আপনার ডাটাবেস অ্যাক্সেস করতে, আপনাকে সেই রুলসগুলি পরিবর্তন করতে হবে এবং ডেভেলপমেন্ট পরিবেশে সমস্ত ব্যবহারকারীকে সম্পূর্ণ অ্যাক্সেস দেওয়ার কথা বিবেচনা করতে পারেন। তবে, আপনার অ্যাপটিকে প্রোডাকশন পরিবেশে স্থাপন করার আগে, আপনার নিয়মগুলি সঠিকভাবে কনফিগার করার এবং আপনার ডেটা সুরক্ষিত করার জন্য সময় নিন।

যখন আপনি আপনার অ্যাপ ডেভেলপ করছেন এবং আপনার নিয়মের জন্য বিভিন্ন কনফিগারেশন পরীক্ষা করছেন, তখন স্থানীয় ডেভেলপমেন্ট পরিবেশে আপনার অ্যাপ চালানোর জন্য Cloud Firestore এমুলেটর ব্যবহার করুন।

অনিরাপদ নিয়ম সহ সাধারণ পরিস্থিতি

Cloud Firestore Security Rules আপনি ডিফল্টভাবে সেট আপ করে থাকতে পারেন অথবা Cloud Firestore দিয়ে আপনার অ্যাপ তৈরির জন্য প্রাথমিকভাবে কাজ করার সময় সেট আপ করে থাকতে পারেন, আপনার অ্যাপ স্থাপনের আগে তা পর্যালোচনা এবং আপডেট করা উচিত। নিম্নলিখিত সাধারণ সমস্যাগুলি এড়িয়ে আপনার ব্যবহারকারীদের ডেটা সঠিকভাবে সুরক্ষিত করুন।

উন্মুক্ত প্রবেশাধিকার

Cloud Firestore সেট আপ করার সময়, আপনি হয়তো ডেভেলপমেন্টের সময় ওপেন অ্যাক্সেসের জন্য নিয়ম সেট করেছেন। আপনার মনে হতে পারে যে আপনিই একমাত্র ব্যক্তি যিনি আপনার অ্যাপ ব্যবহার করছেন, কিন্তু যদি আপনি এটি ব্যবহার করে থাকেন, তাহলে এটি ইন্টারনেটে উপলব্ধ। আপনি যদি ব্যবহারকারীদের প্রমাণীকরণ না করেন এবং নিরাপত্তা নিয়ম কনফিগার না করেন, তাহলে যে কেউ আপনার প্রোজেক্ট আইডি অনুমান করলে ডেটা চুরি, পরিবর্তন বা মুছে ফেলতে পারে।

// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this rule set in production; it allows
// anyone to overwrite your entire database.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{document} {
      // Allow reads and deletion if the current user owns the existing document
      allow read, delete: if request.auth.uid == resource.data.author_uid;
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;

    }
  }
}
  

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      // Allow public reads
      allow read: if true
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;
      // Allow deletion if the current user owns the existing document
      allow delete: if request.auth.uid == resource.data.author_uid;
    }
  }
}
  

যেকোনো অনুমোদিত ব্যবহারকারীর জন্য অ্যাক্সেস

কখনও কখনও, Cloud Firestore Security Rules চেক করে যে কোনও ব্যবহারকারী লগ ইন করেছেন কিনা, কিন্তু সেই প্রমাণীকরণের উপর ভিত্তি করে অ্যাক্সেসকে আরও সীমাবদ্ধ করে না। যদি আপনার নিয়মগুলির মধ্যে একটিতে auth != null , তাহলে নিশ্চিত করুন যে আপনি চান যে কোনও লগ ইন করা ব্যবহারকারীর ডেটাতে অ্যাক্সেস থাকুক।

service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow read, write: if request.auth != null;
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    // Assign roles to all users and refine access based on user roles
    match /some_collection/{document} {
     allow read: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"

     // Note: Checking for roles in your database using `get` (as in the code
     // above) or `exists` carry standard charges for read operations.
    }
  }
}

// Give each user in your database a particular attribute
// and set it to true/false
// Then, use that attribute to grant access to subsets of data
// For example, an "admin" attribute set
// to "true" grants write access to data

service cloud.firestore {
  match /databases/{database}/documents {
    match /collection/{document} {
      allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
      allow read: true;
    }
  }
}
  

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      allow read: if true
      allow write: if request.auth.uid == request.resource.data.author_uid
    }
  }
}
  

যাচাই না করা ইমেল ঠিকানাগুলির জন্য অ্যাক্সেস

কখনও কখনও, Cloud Firestore Security Rules পরীক্ষা করে যে একজন ব্যবহারকারীর ইমেল একটি নির্দিষ্ট ডোমেনের। যদিও এটি সাধারণত একটি ভাল অনুশীলন, সাইন-ইন করার সময় ইমেলগুলি সর্বদা যাচাই করা হয় না যতক্ষণ না ব্যবহারকারী যাচাইকরণ ইমেল পাওয়ার পরে একটি অতিরিক্ত পদক্ষেপ সম্পাদন করে। নিশ্চিত করুন যে আপনি যাচাই করছেন যে ইমেলটি আসলে ব্যবহারকারীর।

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow access based on email domain
    match /some_collection/{document} {
     allow read: if request.auth != null
                 && request.auth.email.endsWith('@example.com')
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow access based on email domain
    match /some_collection/{document} {
     allow read: if request.auth != null
                 && request.auth.email_verified
                 && request.auth.email.endsWith('@example.com')
    }
  }
}

বন্ধ প্রবেশাধিকার

আপনার অ্যাপ তৈরি করার সময়, আরেকটি সাধারণ পদ্ধতি হল আপনার ডেটা লক ডাউন রাখা। সাধারণত, এর অর্থ হল আপনি সমস্ত ব্যবহারকারীর জন্য পঠন এবং লেখার অ্যাক্সেস বন্ধ করে দিয়েছেন, যেমন:

// Deny read/write access to all users under any conditions
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Firebase Admin SDK এবং Cloud Functions এখনও আপনার ডাটাবেস অ্যাক্সেস করতে পারে। Firebase Admin SDK এর সাথে Cloud Firestore সার্ভার-অনলি ব্যাকএন্ড হিসেবে ব্যবহার করার সময় এই নিয়মগুলি ব্যবহার করুন। এটি নিরাপদ থাকা সত্ত্বেও, আপনার অ্যাপের ক্লায়েন্টরা সঠিকভাবে ডেটা পুনরুদ্ধার করতে পারে কিনা তা পরীক্ষা করা উচিত।

Cloud Firestore Security Rules এবং সেগুলি কীভাবে কাজ করে সে সম্পর্কে আরও জানুন "Get Started with Cloud Firestore Security Rules ।

আপনার Cloud Firestore Security Rules পরীক্ষা করুন

আপনার অ্যাপের আচরণ পরীক্ষা করতে এবং আপনার Cloud Firestore Security Rules কনফিগারেশন যাচাই করতে, Cloud Firestore এমুলেটর ব্যবহার করুন। কোনও পরিবর্তন স্থাপন করার আগে স্থানীয় পরিবেশে ইউনিট পরীক্ষা চালানো এবং স্বয়ংক্রিয় করতে Cloud Firestore এমুলেটর ব্যবহার করুন।

ফায়ারবেস কনসোলে আপনার আপডেট করা Cloud Firestore Security Rules দ্রুত পরীক্ষা করতে, রুলস প্লেগ্রাউন্ড টুলটি ব্যবহার করুন।

1. Rules Playground খুলতে, Rules ট্যাব থেকে Rules playground এ ক্লিক করুন।
2. নিয়ম খেলার মাঠ সেটিংসে, আপনার পরীক্ষার জন্য বিকল্পগুলি নির্বাচন করুন, যার মধ্যে রয়েছে:
   • পড়া বা লেখা পরীক্ষা করা হচ্ছে
   • আপনার ডাটাবেসের একটি নির্দিষ্ট অবস্থান , একটি পথ হিসেবে
   • প্রমাণীকরণের ধরণ — অপ্রমাণিত, প্রমাণিত বেনামী ব্যবহারকারী, অথবা একটি নির্দিষ্ট ব্যবহারকারী আইডি
   • আপনার নিয়মাবলীতে বিশেষভাবে উল্লেখ করা ডকুমেন্ট-নির্দিষ্ট ডেটা (উদাহরণস্বরূপ, যদি আপনার নিয়মাবলীতে লেখার অনুমতি দেওয়ার আগে একটি নির্দিষ্ট ক্ষেত্রের উপস্থিতি প্রয়োজন হয়)
3. রান এ ক্লিক করুন এবং নিয়ম উইন্ডোর উপরে ব্যানারে ফলাফলগুলি দেখুন।