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

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

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

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

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

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

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

অনিরাপদ নিয়মগুলির সাথে সাধারণ পরিস্থিতি

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

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

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;
    }
  }
}
সমাধান: পঠন ও লিখন প্রবেশাধিকার সীমিত করার নিয়মাবলী।

আপনার ডেটা হায়ারার্কির জন্য উপযুক্ত নিয়ম তৈরি করুন। এই নিরাপত্তাহীনতার একটি সাধারণ সমাধান হলো Firebase Authentication ব্যবহার করে ব্যবহারকারী-ভিত্তিক নিরাপত্তা। নিয়মের সাহায্যে ব্যবহারকারীদের প্রমাণীকরণ সম্পর্কে আরও জানুন।

শুধুমাত্র বিষয়বস্তুর মালিক

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 এবং এগুলি কীভাবে কাজ করে সে সম্পর্কে আরও জানতে Cloud Firestore Security Rules দিয়ে শুরু করুন" অংশটি দেখুন

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

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

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

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