নিরাপত্তা নিয়মের ভাষা

bookmark_border সেভ করা পৃষ্ঠা গুছিয়ে রাখতে 'সংগ্রহ' ব্যবহার করুন আপনার পছন্দ অনুযায়ী কন্টেন্ট সেভ করুন ও সঠিক বিভাগে রাখুন।

Cloud Firestore এবং Cloud Storage Firebase Security Rules নিম্নলিখিত কাঠামো এবং সিনট্যাক্স ব্যবহার করে:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

আপনি নিয়ম তৈরি করার সময় নিম্নলিখিত মূল ধারণাগুলি বোঝা গুরুত্বপূর্ণ:

• অনুরোধ: allow বিবৃতিতে আমন্ত্রিত পদ্ধতি বা পদ্ধতি। এই পদ্ধতিগুলি আপনি চালানোর অনুমতি দিচ্ছেন। স্ট্যান্ডার্ড পদ্ধতি হল: get , list , create , update , and delete . read এবং write সুবিধার পদ্ধতিগুলি নির্দিষ্ট ডাটাবেস বা স্টোরেজ পাথে বিস্তৃত পঠন এবং লেখার অ্যাক্সেস সক্ষম করে।
• পাথ: ডাটাবেস বা স্টোরেজ অবস্থান, একটি URI পাথ হিসাবে উপস্থাপিত।
• নিয়ম: allow বিবৃতি, যার মধ্যে এমন একটি শর্ত রয়েছে যা একটি অনুরোধের অনুমতি দেয় যদি এটি সত্যে মূল্যায়ন করে।

এই ধারণাগুলির প্রতিটি নীচে আরও বিশদে বর্ণনা করা হয়েছে।

Realtime Database , Firebase Security Rules একটি JSON নথিতে থাকা JavaScript-এর মতো অভিব্যক্তিগুলি নিয়ে গঠিত।

তারা নিম্নলিখিত সিনট্যাক্স ব্যবহার করে:

{
  "rules": {
    "<<path>>": {
    // Allow the request if the condition for each method is true.
      ".read": <<condition>>,
      ".write": <<condition>>,
      ".validate": <<condition>>
    }
  }
}

নিয়মের তিনটি মৌলিক উপাদান রয়েছে:

• পাথ: ডাটাবেসের অবস্থান। এটি আপনার ডাটাবেসের JSON গঠনকে মিরর করে।
• অনুরোধ: এই পদ্ধতিগুলি নিয়ম অ্যাক্সেস মঞ্জুর করতে ব্যবহার করে৷ read এবং write নিয়মগুলি বিস্তৃত পঠন এবং লেখার অ্যাক্সেস মঞ্জুর করে, যখন validate নিয়মগুলি ইনকামিং বা বিদ্যমান ডেটার উপর ভিত্তি করে অ্যাক্সেস মঞ্জুর করার জন্য একটি গৌণ যাচাইকরণ হিসাবে কাজ করে।
• শর্ত: এমন শর্ত যা একটি অনুরোধের অনুমতি দেয় যদি এটি সত্যে মূল্যায়ন করে।

Cloud Firestore এবং Cloud Storage একটি নিয়মের মৌলিক উপাদানগুলি নিম্নরূপ:

• service ঘোষণা: ফায়ারবেস পণ্যের জন্য নিয়ম প্রযোজ্য বলে ঘোষণা করে।
• match ব্লক: নিয়ম প্রযোজ্য ডাটাবেস বা স্টোরেজ বাকেটের একটি পথ সংজ্ঞায়িত করে।
• allow বিবৃতি: পদ্ধতি দ্বারা পৃথক, অ্যাক্সেস প্রদানের জন্য শর্ত প্রদান করে। সমর্থিত পদ্ধতিগুলির মধ্যে রয়েছে: get , list , create , update , delete এবং সুবিধার পদ্ধতিগুলি read এবং write ৷
• ঐচ্ছিক function ঘোষণা: একাধিক নিয়ম জুড়ে ব্যবহারের জন্য শর্ত একত্রিত এবং মোড়ানোর ক্ষমতা প্রদান করুন।

service allow বিবৃতি সহ এক বা একাধিক match ব্লক রয়েছে যা অনুরোধগুলিতে অ্যাক্সেস দেওয়ার শর্ত প্রদান করে। request এবং resource ভেরিয়েবল নিয়ম শর্তে ব্যবহারের জন্য উপলব্ধ. Firebase Security Rules ল্যাঙ্গুয়েজ function ডিক্লেয়ারেশনকেও সমর্থন করে।

সিনট্যাক্স সংস্করণ

syntax বিবৃতি সূত্র লিখতে ব্যবহৃত Firebase নিয়ম ভাষার সংস্করণ নির্দেশ করে। ভাষার সর্বশেষ সংস্করণ v2 ।

rules_version = '2';
service cloud.firestore {
...
}

কোনো rules_version বিবৃতি সরবরাহ করা না হলে, v1 ইঞ্জিন ব্যবহার করে আপনার নিয়মগুলি মূল্যায়ন করা হবে।

সেবা

service ঘোষণায় আপনার নিয়মগুলি প্রযোজ্য Firebase পণ্য বা পরিষেবাটি নির্ধারণ করে৷ আপনি উৎস ফাইল প্রতি শুধুমাত্র একটি service ঘোষণা অন্তর্ভুক্ত করতে পারেন.

service cloud.firestore {
 // Your 'match' blocks with their corresponding 'allow' statements and
 // optional 'function' declarations are contained here
}

service firebase.storage {
  // Your 'match' blocks with their corresponding 'allow' statements and
  // optional 'function' declarations are contained here
}

আপনি যদি Firebase CLI ব্যবহার করে Cloud Firestore এবং Cloud Storage উভয়ের জন্য নিয়মগুলি সংজ্ঞায়িত করেন তবে আপনাকে সেগুলি আলাদা ফাইলে বজায় রাখতে হবে৷

ম্যাচ

একটি match ব্লক একটি path প্যাটার্ন ঘোষণা করে যা অনুরোধকৃত অপারেশনের জন্য পাথের সাথে মিলে যায় (আগত request.path )। match মূল অংশে এক বা একাধিক নেস্টেড match ব্লক থাকতে হবে, বিবৃতি বা function ঘোষণার allow । নেস্টেড match ব্লকের পাথ প্যারেন্ট match ব্লকের পাথের সাথে আপেক্ষিক।

path প্যাটার্ন হল একটি ডিরেক্টরির মতো নাম যাতে ভেরিয়েবল বা ওয়াইল্ডকার্ড থাকতে পারে। path প্যাটার্ন একক-পাথ সেগমেন্ট এবং মাল্টি-পাথ সেগমেন্ট মিলের অনুমতি দেয়। একটি path আবদ্ধ যেকোন ভেরিয়েবলগুলি match স্কোপের মধ্যে দৃশ্যমান হয় বা যে কোনও নেস্টেড স্কোপ যেখানে path ঘোষণা করা হয়।

একটি path প্যাটার্নের সাথে মিলগুলি আংশিক বা সম্পূর্ণ হতে পারে:

• আংশিক মিল: path প্যাটার্ন হল request.path এর একটি উপসর্গ-মিল।
• সম্পূর্ণ মিল: path প্যাটার্ন সমগ্র request.path সাথে মেলে।

একটি সম্পূর্ণ মিল তৈরি হলে ব্লকের মধ্যে নিয়মগুলি মূল্যায়ন করা হয়। যখন একটি আংশিক ম্যাচ করা হয় তখন নেস্টেড match নিয়মগুলি পরীক্ষা করা হয় যে কোনও নেস্টেড path ম্যাচটি সম্পূর্ণ করবে কিনা।

অনুরোধের অনুমতি দেওয়া হবে কিনা তা নির্ধারণ করতে প্রতিটি সম্পূর্ণ match নিয়মগুলি মূল্যায়ন করা হয়। কোনো মিলিত নিয়ম অ্যাক্সেস মঞ্জুর করলে, অনুরোধ অনুমোদিত হয়. যদি কোন মিলিত নিয়ম অ্যাক্সেস মঞ্জুর করে, অনুরোধ অস্বীকার করা হয়.

// Given request.path == /example/hello/nested/path the following
// declarations indicate whether they are a partial or complete match and
// the value of any variables visible within the scope.
service firebase.storage {
  // Partial match.
  match /example/{singleSegment} {   // `singleSegment` == 'hello'
    allow write;                     // Write rule not evaluated.
    // Complete match.
    match /nested/path {             // `singleSegment` visible in scope.
      allow read;                    // Read rule is evaluated.
    }
  }
  // Complete match.
  match /example/{multiSegment=**} { // `multiSegment` == /hello/nested/path
    allow read;                      // Read rule is evaluated.
  }
}

উপরের উদাহরণটি দেখায়, path ঘোষণা নিম্নলিখিত ভেরিয়েবলগুলিকে সমর্থন করে:

• একক-সেগমেন্ট ওয়াইল্ডকার্ড: একটি ওয়াইল্ডকার্ড ভেরিয়েবলকে একটি পাথে ঘোষণা করা হয় একটি ভেরিয়েবলকে কোঁকড়া বন্ধনীতে মোড়ানো: {variable} । এই ভেরিয়েবলটি একটি string হিসাবে match স্টেটমেন্টের মধ্যে অ্যাক্সেসযোগ্য।
• রিকার্সিভ ওয়াইল্ডকার্ড: রিকার্সিভ, বা মাল্টি-সেগমেন্ট, ওয়াইল্ডকার্ড একটি পাথে বা নীচে একাধিক পাথ সেগমেন্টের সাথে মেলে। এই ওয়াইল্ডকার্ডটি আপনার সেট করা অবস্থানের নীচের সমস্ত পথের সাথে মেলে৷ আপনি আপনার সেগমেন্ট ভেরিয়েবলের শেষে =** স্ট্রিং যোগ করে এটি ঘোষণা করতে পারেন: {variable=**} । এই ভেরিয়েবলটি একটি path অবজেক্ট হিসাবে match স্টেটমেন্টের মধ্যে অ্যাক্সেসযোগ্য।

অনুমতি দিন

match ব্লকে এক বা একাধিক allow বিবৃতি রয়েছে। এগুলি আপনার আসল নিয়ম। আপনি এক বা একাধিক পদ্ধতিতে allow বিধি প্রয়োগ করতে পারেন। Cloud Firestore বা Cloud Storage যেকোনও ইনকামিং অনুরোধ মঞ্জুর করার জন্য একটি allow বিবৃতির শর্তগুলিকে সত্য বলে মূল্যায়ন করতে হবে। আপনি শর্ত ছাড়া allow বিবৃতিও লিখতে পারেন, উদাহরণস্বরূপ, allow read । যদি allow বিবৃতিতে একটি শর্ত অন্তর্ভুক্ত না থাকে, তবে, এটি সর্বদা সেই পদ্ধতির অনুরোধের অনুমতি দেয়।

যদি পদ্ধতির জন্য allow নিয়মগুলির কোনোটি সন্তুষ্ট হয়, অনুরোধটি অনুমোদিত। অতিরিক্তভাবে, যদি একটি বৃহত্তর নিয়ম অ্যাক্সেস মঞ্জুর করে, Rules অ্যাক্সেস মঞ্জুর করে এবং অ্যাক্সেসকে সীমিত করতে পারে এমন আরও কোনো দানাদার নিয়ম উপেক্ষা করে।

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

service firebase.storage {
  // Allow the requestor to read or delete any resource on a path under the
  // user directory.
  match /users/{userId}/{anyUserFile=**} {
    allow read, delete: if request.auth != null && request.auth.uid == userId;
  }

  // Allow the requestor to create or update their own images.
  // When 'request.method' == 'delete' this rule and the one matching
  // any path under the user directory would both match and the `delete`
  // would be permitted.

  match /users/{userId}/images/{imageId} {
    // Whether to permit the request depends on the logical OR of all
    // matched rules. This means that even if this rule did not explicitly
    // allow the 'delete' the earlier rule would have.
    allow write: if request.auth != null && request.auth.uid == userId && imageId.matches('*.png');
  }
}

পদ্ধতি

প্রতিটি allow বিবৃতিতে একটি পদ্ধতি রয়েছে যা একই পদ্ধতির আগত অনুরোধগুলির জন্য অ্যাক্সেস মঞ্জুর করে।

আপনি একই match ব্লকে পঠিত পদ্ধতিগুলিকে ওভারল্যাপ করতে পারবেন না বা একই path ঘোষণায় বিরোধপূর্ণ লেখার পদ্ধতিগুলিকে ওভারল্যাপ করতে পারবেন না৷

উদাহরণস্বরূপ, নিম্নলিখিত নিয়মগুলি ব্যর্থ হবে:

service bad.example {
  match /rules/with/overlapping/methods {
    // This rule allows reads to all authenticated users
    allow read: if request.auth != null;

    match another/subpath {
      // This secondary, more specific read rule causes an error
      allow get: if request.auth != null && request.auth.uid == "me";
      // Overlapping write methods in the same path cause an error as well
      allow write: if request.auth != null;
      allow create: if request.auth != null && request.auth.uid == "me";
    }
  }
}

ফাংশন

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

• ফাংশনে শুধুমাত্র একটি return স্টেটমেন্ট থাকতে পারে। তারা কোন অতিরিক্ত যুক্তি ধারণ করতে পারে না. উদাহরণস্বরূপ, তারা লুপ চালাতে পারে না বা বহিরাগত পরিষেবাগুলিকে কল করতে পারে না।
• ফাংশনগুলি স্বয়ংক্রিয়ভাবে ফাংশন এবং ভেরিয়েবলগুলিকে যে সুযোগে সংজ্ঞায়িত করা হয়েছে তা থেকে অ্যাক্সেস করতে পারে। উদাহরণস্বরূপ, service cloud.firestore স্কোপের মধ্যে সংজ্ঞায়িত একটি ফাংশন resource ভেরিয়েবল এবং বিল্ট-ইন ফাংশন যেমন get() এবং exists() অ্যাক্সেস করতে পারে।
• ফাংশন অন্যান্য ফাংশন কল করতে পারে কিন্তু পুনরাবৃত্তি নাও হতে পারে। মোট কল স্ট্যাকের গভীরতা 20-এর মধ্যে সীমাবদ্ধ।
• নিয়ম সংস্করণ v2 , ফাংশন let কীওয়ার্ড ব্যবহার করে ভেরিয়েবলকে সংজ্ঞায়িত করতে পারে। ফাংশনে 10 পর্যন্ত লেট বাইন্ডিং থাকতে পারে, কিন্তু একটি রিটার্ন স্টেটমেন্ট দিয়ে শেষ করতে হবে।

একটি ফাংশন function কীওয়ার্ড দিয়ে সংজ্ঞায়িত করা হয় এবং শূন্য বা তার বেশি আর্গুমেন্ট নেয়। উদাহরণস্বরূপ, আপনি একটি একক ফাংশনে উপরের উদাহরণগুলিতে ব্যবহৃত দুটি ধরণের শর্ত একত্রিত করতে চাইতে পারেন:

service cloud.firestore {
  match /databases/{database}/documents {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }

    match /cities/{city} {
      allow read, write: if signedInOrPublic();
    }

    match /users/{user} {
      allow read, write: if signedInOrPublic();
    }
  }
}

এখানে ফাংশন আর্গুমেন্ট এবং লেট অ্যাসাইনমেন্ট দেখানোর একটি উদাহরণ। অ্যাসাইনমেন্ট স্টেটমেন্ট সেমিকোলন দ্বারা পৃথক করা আবশ্যক.

function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  let isAdmin = exists(/databases/$(database)/documents/admins/$(userId));
  return isAuthor || isAdmin;
}

লক্ষ্য করুন কিভাবে isAdmin অ্যাসাইনমেন্ট প্রশাসক সংগ্রহের একটি লুকআপ প্রয়োগ করে। অপ্রয়োজনীয় লুকআপের প্রয়োজন ছাড়াই অলস মূল্যায়নের জন্য, && (AND) এবং || এর শর্ট-সার্কিট প্রকৃতির সুবিধা নিন। (অথবা) একটি দ্বিতীয় ফাংশন কল করার জন্য তুলনা শুধুমাত্র যদি isAuthor সত্য ( && তুলনার জন্য) বা মিথ্যা ( || তুলনার জন্য) দেখানো হয়।

function isAdmin(userId) {
  return exists(/databases/$(database)/documents/admins/$(userId));
}
function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  // `||` is short-circuiting; isAdmin called only if isAuthor == false.
  return isAuthor || isAdmin(userId);
}

আপনার নিরাপত্তা নিয়মে ফাংশন ব্যবহার করা আপনার নিয়মের জটিলতা বাড়ার সাথে সাথে সেগুলিকে আরও রক্ষণাবেক্ষণযোগ্য করে তোলে।

উপরে উল্লিখিত হিসাবে, Realtime Database Rules তিনটি মৌলিক উপাদান রয়েছে: ডাটাবেসের JSON কাঠামোর মিরর হিসাবে ডাটাবেসের অবস্থান, অনুরোধের ধরন এবং অ্যাক্সেস দেওয়ার শর্ত।

ডাটাবেস অবস্থান

আপনার নিয়মের কাঠামো আপনার ডাটাবেসে সংরক্ষিত ডেটার কাঠামো অনুসরণ করা উচিত। উদাহরণস্বরূপ, বার্তাগুলির একটি তালিকা সহ একটি চ্যাট অ্যাপে, আপনার কাছে এমন ডেটা থাকতে পারে যা দেখতে এইরকম:

  {
    "messages": {
      "message0": {
        "content": "Hello",
        "timestamp": 1405704370369
      },
      "message1": {
        "content": "Goodbye",
        "timestamp": 1405704395231
      },
      ...
    }
  }

আপনার নিয়ম যে কাঠামো মিরর করা উচিত. যেমন:

  {
    "rules": {
      "messages": {
        "$message": {
          // only messages from the last ten minutes can be read
          ".read": "data.child('timestamp').val() > (now - 600000)",

          // new messages must have a string content and a number timestamp
          ".validate": "newData.hasChildren(['content', 'timestamp']) &&
                        newData.child('content').isString() &&
                        newData.child('timestamp').isNumber()"
        }
      }
    }
  }

উপরের উদাহরণটি দেখায়, Realtime Database Rules পাথের অংশগুলিকে মেলানোর জন্য একটি $location পরিবর্তনশীলকে সমর্থন করে। পাথের পাশে থাকা যেকোনো চাইল্ড নোডের সাথে আপনার নিয়ম মেলে আপনার পাথ সেগমেন্টের সামনে $ উপসর্গ ব্যবহার করুন।

  {
    "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')"
          }
        }
      }
    }
  }

আপনি ধ্রুবক পাথ নামের সাথে সমান্তরালে $variable ব্যবহার করতে পারেন।

  {
    "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 }
      }
    }
  }

পদ্ধতি

Realtime Database , তিন ধরনের নিয়ম রয়েছে। এই নিয়মের দুটি ধরন — read এবং write — একটি আগত অনুরোধের পদ্ধতিতে প্রয়োগ করুন৷ validate নিয়মের ধরন ডেটা স্ট্রাকচার প্রয়োগ করে এবং ডেটার বিন্যাস এবং বিষয়বস্তুকে বৈধ করে। .write নিয়ম অ্যাক্সেসের অনুমতি দেয় তা যাচাই করার পরে Rules চলে .validate ৷

ডিফল্টরূপে, যদি এটির অনুমতি দেওয়ার নিয়ম না থাকে, তবে একটি পাথে অ্যাক্সেস অস্বীকার করা হয়।

একটি শর্ত একটি বুলিয়ান অভিব্যক্তি যা নির্ধারণ করে যে একটি নির্দিষ্ট অপারেশন অনুমোদিত বা অস্বীকার করা উচিত। request এবং resource ভেরিয়েবলগুলি সেই শর্তগুলির জন্য প্রসঙ্গ প্রদান করে।

request পরিবর্তনশীল

request পরিবর্তনশীল নিম্নলিখিত ক্ষেত্র এবং সংশ্লিষ্ট তথ্য অন্তর্ভুক্ত:

request.auth

একটি JSON ওয়েব টোকেন (JWT) যাতে Firebase Authentication থেকে প্রমাণীকরণের প্রমাণপত্র রয়েছে। auth টোকেনে স্ট্যান্ডার্ড দাবির একটি সেট এবং Firebase Authentication মাধ্যমে আপনি যে কোনো কাস্টম দাবি তৈরি করেন। Firebase Security Rules এবং Authentication সম্পর্কে আরও জানুন।

request.method

request.method মানক পদ্ধতি বা একটি কাস্টম পদ্ধতি হতে পারে। read এবং write সুবিধার পদ্ধতিগুলিও লেখার নিয়মগুলিকে সরল করার জন্য বিদ্যমান যা যথাক্রমে সমস্ত পঠন-পাঠন বা সমস্ত লেখার জন্য প্রযোজ্য।

request.params

request.params এমন কোনো ডেটা অন্তর্ভুক্ত থাকে যা বিশেষভাবে request.resource এর সাথে সম্পর্কিত নয় যা মূল্যায়নের জন্য উপযোগী হতে পারে। অনুশীলনে, এই মানচিত্রটি সমস্ত মানক পদ্ধতির জন্য খালি হওয়া উচিত এবং কাস্টম পদ্ধতির জন্য অ-সম্পদ ডেটা থাকা উচিত। পরিষেবাগুলিকে প্যারাম হিসাবে উপস্থাপিত কোনও কী এবং মানগুলির প্রকারের নাম পরিবর্তন বা পরিবর্তন না করার বিষয়ে সতর্ক থাকতে হবে।

request.path

request.path হল টার্গেট resource পথ। পথ সেবার আপেক্ষিক। নন-ইউআরএল নিরাপদ অক্ষর ধারণকারী পাথ সেগমেন্ট যেমন / ইউআরএল-এনকোডেড।

resource পরিবর্তনশীল

resource হল পরিষেবার মধ্যে বর্তমান মান যা কী-মান জোড়ার মানচিত্র হিসাবে উপস্থাপিত হয়। একটি শর্তের মধ্যে resource উল্লেখ করার ফলে পরিষেবা থেকে সর্বাধিক একটি মূল্য পড়া হবে। এই লুকআপটি সম্পদের জন্য যেকোন পরিষেবা-সম্পর্কিত কোটার বিরুদ্ধে গণনা করা হবে। রিকোয়েস্ট get জন্য, resource শুধুমাত্র অস্বীকৃত হলে কোটার দিকে গণনা করা হবে।

অপারেটর এবং অপারেটর অগ্রাধিকার

Cloud Firestore এবং Cloud Storage Rules অপারেটর এবং তাদের সংশ্লিষ্ট অগ্রাধিকারের রেফারেন্স হিসাবে নীচের টেবিলটি ব্যবহার করুন।

প্রদত্ত নির্বিচারে অভিব্যক্তি a এবং b , একটি ক্ষেত্র f , এবং একটি সূচক i .

একটি শর্ত একটি বুলিয়ান অভিব্যক্তি যা নির্ধারণ করে যে একটি নির্দিষ্ট অপারেশন অনুমোদিত বা অস্বীকার করা উচিত। আপনি নিম্নলিখিত উপায়ে Realtime Database Rules সেই শর্তগুলি সংজ্ঞায়িত করতে পারেন।

পূর্ব-নির্ধারিত ভেরিয়েবল

অনেকগুলি সহায়ক, পূর্ব-সংজ্ঞায়িত ভেরিয়েবল রয়েছে যা একটি নিয়ম সংজ্ঞার মধ্যে অ্যাক্সেস করা যেতে পারে। এখানে প্রতিটির একটি সংক্ষিপ্ত সারসংক্ষেপ রয়েছে:

এই ভেরিয়েবলগুলি আপনার নিয়মের যেকোনো জায়গায় ব্যবহার করা যেতে পারে। উদাহরণস্বরূপ, নীচের নিরাপত্তা নিয়মগুলি নিশ্চিত করে যে /foo/ নোডে লেখা ডেটা অবশ্যই 100 অক্ষরের কম একটি স্ট্রিং হতে হবে:

{
  "rules": {
    "foo": {
      // /foo is readable by the world
      ".read": true,

      // /foo is writable by the world
      ".write": true,

      // data written to /foo must be a string less than 100 characters
      ".validate": "newData.isString() && newData.val().length < 100"
    }
  }
}

ডেটা ভিত্তিক নিয়ম

আপনার ডাটাবেসের যেকোনো ডাটা আপনার নিয়মে ব্যবহার করা যাবে। পূর্বনির্ধারিত ভেরিয়েবল root , data , এবং newData ব্যবহার করে, আপনি যে কোনও পাথ অ্যাক্সেস করতে পারেন কারণ এটি একটি লেখার ইভেন্টের আগে বা পরে থাকবে।

এই উদাহরণটি বিবেচনা করুন, যা /allow_writes/ নোডের মান true হওয়া পর্যন্ত লেখার ক্রিয়াকলাপকে অনুমতি দেয়, প্যারেন্ট নোডের একটি readOnly পতাকা সেট থাকে না এবং নতুন লেখা ডেটাতে foo নামে একটি শিশু রয়েছে:

".write": "root.child('allow_writes').val() === true &&
          !data.parent().child('readOnly').exists() &&
          newData.child('foo').exists()"

প্রশ্ন ভিত্তিক নিয়ম

যদিও আপনি নিয়মগুলিকে ফিল্টার হিসাবে ব্যবহার করতে পারবেন না, আপনি আপনার নিয়মে ক্যোয়ারী প্যারামিটার ব্যবহার করে ডেটার উপসেটগুলিতে অ্যাক্সেস সীমিত করতে পারেন৷ query. ক্যোয়ারী প্যারামিটারের উপর ভিত্তি করে পঠন বা লেখার অ্যাক্সেস মঞ্জুর করতে আপনার নিয়মে অভিব্যক্তি।

উদাহরণ স্বরূপ, নিম্নলিখিত ক্যোয়ারী-ভিত্তিক নিয়ম ব্যবহারকারী-ভিত্তিক নিরাপত্তা নিয়ম এবং ক্যোয়ারী-ভিত্তিক নিয়মগুলি ব্যবহার করে baskets সংগ্রহের ডেটা অ্যাক্সেসকে শুধুমাত্র সক্রিয় ব্যবহারকারীর মালিকানাধীন শপিং বাস্কেটে সীমাবদ্ধ করতে:

"baskets": {
  ".read": "auth.uid !== null &&
            query.orderByChild === 'owner' &&
            query.equalTo === auth.uid" // restrict basket access to owner of basket
}

নিম্নোক্ত ক্যোয়ারী, যার মধ্যে নিয়মের ক্যোয়ারী প্যারামিটার রয়েছে, সফল হবে:

db.ref("baskets").orderByChild("owner")
                 .equalTo(auth.currentUser.uid)
                 .on("value", cb)                 // Would succeed

যাইহোক, নিয়মের প্যারামিটারগুলি অন্তর্ভুক্ত করে না এমন প্রশ্নগুলি PermissionDenied ত্রুটির সাথে ব্যর্থ হবে:

db.ref("baskets").on("value", cb)                 // Would fail with PermissionDenied

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

উদাহরণ স্বরূপ, নিম্নোক্ত নিয়মটি অগ্রাধিকার দ্বারা আদেশ অনুসারে একটি প্রশ্নের প্রথম 1000টি ফলাফলে পড়ার অ্যাক্সেসকে সীমাবদ্ধ করে:

messages: {
  ".read": "query.orderByKey &&
            query.limitToFirst <= 1000"
}

// Example queries:

db.ref("messages").on("value", cb)                // Would fail with PermissionDenied

db.ref("messages").limitToFirst(1000)
                  .on("value", cb)                // Would succeed (default order by key)

নিম্নলিখিত query. এক্সপ্রেশনগুলি Realtime Database Security Rules উপলব্ধ।

অপারেটর

Realtime Database Rules বেশ কয়েকটি অপারেটরকে সমর্থন করে যা আপনি শর্ত বিবৃতিতে ভেরিয়েবলগুলিকে একত্রিত করতে ব্যবহার করতে পারেন। রেফারেন্স ডকুমেন্টেশনে অপারেটরদের সম্পূর্ণ তালিকা দেখুন।

Cloud Firestore এবং Cloud Storage Firebase Security Rules নিম্নলিখিত কাঠামো এবং সিনট্যাক্স ব্যবহার করে:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

আপনি নিয়ম তৈরি করার সময় নিম্নলিখিত মূল ধারণাগুলি বোঝা গুরুত্বপূর্ণ:

• অনুরোধ: allow বিবৃতিতে আমন্ত্রিত পদ্ধতি বা পদ্ধতি। এই পদ্ধতিগুলি আপনি চালানোর অনুমতি দিচ্ছেন। স্ট্যান্ডার্ড পদ্ধতি হল: get , list , create , update , and delete . read এবং write সুবিধার পদ্ধতিগুলি নির্দিষ্ট ডাটাবেস বা স্টোরেজ পাথে বিস্তৃত পঠন এবং লেখার অ্যাক্সেস সক্ষম করে।
• পাথ: ডাটাবেস বা স্টোরেজ অবস্থান, একটি URI পাথ হিসাবে উপস্থাপিত।
• নিয়ম: allow বিবৃতি, যার মধ্যে এমন একটি শর্ত রয়েছে যা একটি অনুরোধের অনুমতি দেয় যদি এটি সত্যে মূল্যায়ন করে।

এই ধারণাগুলির প্রতিটি নীচে আরও বিশদে বর্ণনা করা হয়েছে।

Realtime Database , Firebase Security Rules একটি JSON নথিতে থাকা JavaScript-এর মতো অভিব্যক্তিগুলি নিয়ে গঠিত।

তারা নিম্নলিখিত সিনট্যাক্স ব্যবহার করে:

{
  "rules": {
    "<<path>>": {
    // Allow the request if the condition for each method is true.
      ".read": <<condition>>,
      ".write": <<condition>>,
      ".validate": <<condition>>
    }
  }
}

নিয়মের তিনটি মৌলিক উপাদান রয়েছে:

• পাথ: ডাটাবেসের অবস্থান। এটি আপনার ডাটাবেসের JSON গঠনকে মিরর করে।
• অনুরোধ: এই পদ্ধতিগুলি নিয়ম অ্যাক্সেস মঞ্জুর করতে ব্যবহার করে৷ read এবং write নিয়মগুলি বিস্তৃত পঠন এবং লেখার অ্যাক্সেস মঞ্জুর করে, যখন validate নিয়মগুলি ইনকামিং বা বিদ্যমান ডেটার উপর ভিত্তি করে অ্যাক্সেস মঞ্জুর করার জন্য একটি গৌণ যাচাইকরণ হিসাবে কাজ করে।
• শর্ত: এমন শর্ত যা একটি অনুরোধের অনুমতি দেয় যদি এটি সত্যে মূল্যায়ন করে।

Cloud Firestore এবং Cloud Storage একটি নিয়মের প্রাথমিক উপাদানগুলি নিম্নরূপ:

• service ঘোষণা: ফায়ারবেস পণ্যটি প্রযোজ্য বিধিগুলি ঘোষণা করে।
• match ব্লক: ডাটাবেস বা স্টোরেজ বালতিতে একটি পাথ সংজ্ঞায়িত করে নিয়মগুলি প্রযোজ্য।
• allow বিবৃতি: অ্যাক্সেস মঞ্জুর করার জন্য শর্তাদি সরবরাহ করে, পদ্ধতি দ্বারা পৃথক। সমর্থিত পদ্ধতিগুলির মধ্যে রয়েছে: get , list , create , update , delete এবং সুবিধামত পদ্ধতিগুলি read এবং write ।
• Al চ্ছিক function ঘোষণা: একাধিক বিধি জুড়ে ব্যবহারের জন্য শর্তাদি একত্রিত এবং মোড়ানোর ক্ষমতা সরবরাহ করুন।

service এক বা একাধিক match ব্লক রয়েছে যা allow যা অনুরোধগুলিতে অ্যাক্সেস প্রদানের শর্তাদি সরবরাহ করে। request এবং resource ভেরিয়েবলগুলি নিয়মের শর্তে ব্যবহারের জন্য উপলব্ধ। Firebase Security Rules ভাষাও function ঘোষণাকে সমর্থন করে।

সিনট্যাক্স সংস্করণ

syntax বিবৃতি উত্সটি লেখার জন্য ব্যবহৃত ফায়ারবেস নিয়ম ভাষার সংস্করণ নির্দেশ করে। ভাষার সর্বশেষতম সংস্করণটি v2 ।

rules_version = '2';
service cloud.firestore {
...
}

যদি কোনও rules_version বিবৃতি সরবরাহ না করা হয় তবে আপনার বিধিগুলি v1 ইঞ্জিন ব্যবহার করে মূল্যায়ন করা হবে।

সেবা

service ঘোষণাপত্রটি কোন ফায়ারবেস পণ্য বা পরিষেবা, আপনার নিয়মগুলি প্রযোজ্য তা নির্ধারণ করে। আপনি কেবল উত্স ফাইল প্রতি একটি service ঘোষণা অন্তর্ভুক্ত করতে পারেন।

service cloud.firestore {
 // Your 'match' blocks with their corresponding 'allow' statements and
 // optional 'function' declarations are contained here
}

service firebase.storage {
  // Your 'match' blocks with their corresponding 'allow' statements and
  // optional 'function' declarations are contained here
}

আপনি যদি Firebase সিএলআই ব্যবহার করে Cloud Firestore এবং Cloud Storage উভয়ের জন্য নিয়মগুলি সংজ্ঞায়িত করছেন তবে আপনাকে সেগুলি পৃথক ফাইলগুলিতে বজায় রাখতে হবে।

ম্যাচ

একটি match ব্লক একটি path প্যাটার্ন ঘোষণা করে যা অনুরোধ করা অপারেশনের (আগত request.path ) এর পথের সাথে মিলে যায়। match বডিটিতে অবশ্যই এক বা একাধিক নেস্টেড match ব্লক থাকতে হবে, বিবৃতি দেওয়া বা function ঘোষণার allow । নেস্টেড match ব্লকের পথটি প্যারেন্ট match ব্লকের পথের সাথে সম্পর্কিত।

path প্যাটার্নটি একটি ডিরেক্টরি-জাতীয় নাম যা ভেরিয়েবল বা ওয়াইল্ডকার্ডগুলি অন্তর্ভুক্ত করতে পারে। path প্যাটার্নটি একক-পাথ বিভাগ এবং মাল্টি-পাথ বিভাগের ম্যাচগুলির জন্য অনুমতি দেয়। কোনও path আবদ্ধ যে কোনও ভেরিয়েবলগুলি match সুযোগ বা কোনও নেস্টেড স্কোপের মধ্যে দৃশ্যমান যেখানে path ঘোষণা করা হয়েছে।

কোনও path প্যাটার্নের বিরুদ্ধে ম্যাচগুলি আংশিক বা সম্পূর্ণ হতে পারে:

• আংশিক ম্যাচ: path প্যাটার্নটি request.path একটি উপসর্গ-ম্যাচ।
• সম্পূর্ণ ম্যাচ: path প্যাটার্নটি পুরো request.path সাথে মেলে।

যখন একটি সম্পূর্ণ ম্যাচ তৈরি করা হয় তখন ব্লকের মধ্যে নিয়মগুলি মূল্যায়ন করা হয়। যখন একটি আংশিক ম্যাচ তৈরি করা হয় তখন নেস্টেড match নিয়মগুলি পরীক্ষা করা হয় যে কোনও নেস্টেড path ম্যাচটি শেষ করবে কিনা তা দেখার জন্য।

প্রতিটি সম্পূর্ণ match নিয়মগুলি অনুরোধের অনুমতি দেবে কিনা তা নির্ধারণের জন্য মূল্যায়ন করা হয়। যদি কোনও মিলে যাওয়া নিয়ম অ্যাক্সেস মঞ্জুরি দেয় তবে অনুরোধটি অনুমোদিত। যদি কোনও মিলে যাওয়া নিয়ম অ্যাক্সেসের অনুমতি দেয় না, অনুরোধটি অস্বীকার করা হয়।

// Given request.path == /example/hello/nested/path the following
// declarations indicate whether they are a partial or complete match and
// the value of any variables visible within the scope.
service firebase.storage {
  // Partial match.
  match /example/{singleSegment} {   // `singleSegment` == 'hello'
    allow write;                     // Write rule not evaluated.
    // Complete match.
    match /nested/path {             // `singleSegment` visible in scope.
      allow read;                    // Read rule is evaluated.
    }
  }
  // Complete match.
  match /example/{multiSegment=**} { // `multiSegment` == /hello/nested/path
    allow read;                      // Read rule is evaluated.
  }
}

উপরের উদাহরণটি যেমন দেখায়, path ঘোষণাগুলি নিম্নলিখিত ভেরিয়েবলগুলিকে সমর্থন করে:

• একক বিভাগের ওয়াইল্ডকার্ড: কোঁকড়ানো ধনুর্বন্ধনীগুলিতে একটি ভেরিয়েবল মোড়ক করে একটি ওয়াইল্ডকার্ড ভেরিয়েবল একটি পথে ঘোষণা করা হয়: {variable} এই পরিবর্তনশীলটি string হিসাবে match বিবৃতিতে অ্যাক্সেসযোগ্য।
• পুনরাবৃত্ত ওয়াইল্ডকার্ড: পুনরাবৃত্ত বা বহু-বিভাগ, ওয়াইল্ডকার্ড একটি পথ বা নীচে একাধিক পাথ বিভাগের সাথে মেলে। এই ওয়াইল্ডকার্ডটি আপনি যে স্থানে সেট করেছেন তার নীচে সমস্ত পাথের সাথে মেলে। আপনি আপনার বিভাগের ভেরিয়েবলের শেষে =** স্ট্রিং যুক্ত করে এটি ঘোষণা করতে পারেন: {variable=**} এই পরিবর্তনশীলটি একটি path অবজেক্ট হিসাবে match বিবৃতিতে অ্যাক্সেসযোগ্য।

অনুমতি দিন

match ব্লকে এক বা একাধিক বিবৃতি allow । এগুলি আপনার আসল নিয়ম। আপনি এক বা একাধিক পদ্ধতিতে বিধি allow প্রয়োগ করতে পারেন। কোনও আগত অনুরোধ মঞ্জুর করার জন্য কোনও allow বিবৃতিতে শর্তগুলি Cloud Firestore বা Cloud Storage জন্য সত্যকে মূল্যায়ন করতে হবে। আপনি শর্ত ছাড়াই বিবৃতি allow লিখতে পারেন, উদাহরণস্বরূপ, allow read । যদি allow বিবৃতিতে কোনও শর্ত অন্তর্ভুক্ত না হয় তবে এটি সর্বদা সেই পদ্ধতির জন্য অনুরোধের অনুমতি দেয়।

পদ্ধতির জন্য যদি কোনও allow বিধি সন্তুষ্ট হয় তবে অনুরোধটি অনুমোদিত। অতিরিক্তভাবে, যদি কোনও বিস্তৃত নিয়ম অ্যাক্সেসকে মঞ্জুরি দেয়, Rules অ্যাক্সেসকে মঞ্জুর করে এবং আরও কোনও দানাদার বিধি উপেক্ষা করে যা অ্যাক্সেসকে সীমাবদ্ধ করতে পারে।

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

service firebase.storage {
  // Allow the requestor to read or delete any resource on a path under the
  // user directory.
  match /users/{userId}/{anyUserFile=**} {
    allow read, delete: if request.auth != null && request.auth.uid == userId;
  }

  // Allow the requestor to create or update their own images.
  // When 'request.method' == 'delete' this rule and the one matching
  // any path under the user directory would both match and the `delete`
  // would be permitted.

  match /users/{userId}/images/{imageId} {
    // Whether to permit the request depends on the logical OR of all
    // matched rules. This means that even if this rule did not explicitly
    // allow the 'delete' the earlier rule would have.
    allow write: if request.auth != null && request.auth.uid == userId && imageId.matches('*.png');
  }
}

পদ্ধতি

প্রতিটি allow বিবৃতিতে এমন একটি পদ্ধতি অন্তর্ভুক্ত থাকে যা একই পদ্ধতির আগত অনুরোধগুলির জন্য অ্যাক্সেসকে মঞ্জুরি দেয়।

আপনি একই match ব্লকে পড়ার পদ্ধতিগুলি বা একই path ঘোষণায় বিবাদী লেখার পদ্ধতিগুলি ওভারল্যাপ করতে পারবেন না।

উদাহরণস্বরূপ, নিম্নলিখিত নিয়মগুলি ব্যর্থ হবে:

service bad.example {
  match /rules/with/overlapping/methods {
    // This rule allows reads to all authenticated users
    allow read: if request.auth != null;

    match another/subpath {
      // This secondary, more specific read rule causes an error
      allow get: if request.auth != null && request.auth.uid == "me";
      // Overlapping write methods in the same path cause an error as well
      allow write: if request.auth != null;
      allow create: if request.auth != null && request.auth.uid == "me";
    }
  }
}

ফাংশন

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

• ফাংশনে শুধুমাত্র একটি return স্টেটমেন্ট থাকতে পারে। তারা কোন অতিরিক্ত যুক্তি ধারণ করতে পারে না. উদাহরণস্বরূপ, তারা লুপ চালাতে পারে না বা বহিরাগত পরিষেবাগুলিকে কল করতে পারে না।
• ফাংশনগুলি স্বয়ংক্রিয়ভাবে ফাংশন এবং ভেরিয়েবলগুলিকে যে সুযোগে সংজ্ঞায়িত করা হয়েছে তা থেকে অ্যাক্সেস করতে পারে। উদাহরণস্বরূপ, service cloud.firestore মধ্যে সংজ্ঞায়িত একটি ফাংশন Firestore স্কোপটিতে resource ভেরিয়েবল এবং অন্তর্নির্মিত ফাংশন যেমন get() এবং exists() এর অ্যাক্সেস রয়েছে।
• ফাংশন অন্যান্য ফাংশন কল করতে পারে কিন্তু পুনরাবৃত্তি নাও হতে পারে। মোট কল স্ট্যাক গভীরতা 20 এর মধ্যে সীমাবদ্ধ।
• বিধি সংস্করণ v2 -তে, ফাংশনগুলি let কীওয়ার্ডটি ব্যবহার করে ভেরিয়েবলগুলি সংজ্ঞায়িত করতে পারে। ফাংশনগুলিতে 10 টি পর্যন্ত বাইন্ডিং থাকতে পারে তবে অবশ্যই একটি রিটার্ন স্টেটমেন্ট দিয়ে শেষ করতে হবে।

একটি ফাংশন function কীওয়ার্ড দিয়ে সংজ্ঞায়িত করা হয় এবং শূন্য বা তার বেশি আর্গুমেন্ট নেয়। উদাহরণস্বরূপ, আপনি একটি একক ফাংশনে উপরের উদাহরণগুলিতে ব্যবহৃত দুটি ধরণের শর্ত একত্রিত করতে চাইতে পারেন:

service cloud.firestore {
  match /databases/{database}/documents {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }

    match /cities/{city} {
      allow read, write: if signedInOrPublic();
    }

    match /users/{user} {
      allow read, write: if signedInOrPublic();
    }
  }
}

এখানে একটি উদাহরণ ফাংশন যুক্তি দেখানো এবং অ্যাসাইনমেন্ট দিন। অ্যাসাইনমেন্ট স্টেটমেন্টগুলি অবশ্যই সেমিকোলন দ্বারা পৃথক করা উচিত।

function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  let isAdmin = exists(/databases/$(database)/documents/admins/$(userId));
  return isAuthor || isAdmin;
}

isAdmin অ্যাসাইনমেন্ট কীভাবে প্রশাসনিক সংগ্রহের সন্ধানকে কার্যকর করে তা নোট করুন। অলস মূল্যায়নের জন্য অপ্রয়োজনীয় অনুসন্ধানের প্রয়োজন ছাড়াই, && (এবং) এর স্বল্প-উত্সাহী প্রকৃতির সুবিধা নিন এবং || (বা) দ্বিতীয় ফাংশন কল করার জন্য তুলনাগুলি কেবল তখনই যদি isAuthor সত্য ( && তুলনার জন্য) বা মিথ্যা ( || তুলনাগুলির জন্য) দেখানো হয়।

function isAdmin(userId) {
  return exists(/databases/$(database)/documents/admins/$(userId));
}
function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  // `||` is short-circuiting; isAdmin called only if isAuthor == false.
  return isAuthor || isAdmin(userId);
}

আপনার সুরক্ষা বিধিগুলিতে ফাংশনগুলি ব্যবহার করা আপনার নিয়মের জটিলতা বাড়ার সাথে সাথে তাদের আরও রক্ষণাবেক্ষণযোগ্য করে তোলে।

উপরে বর্ণিত হিসাবে, Realtime Database Rules তিনটি প্রাথমিক উপাদান অন্তর্ভুক্ত রয়েছে: ডাটাবেসের জেএসএন কাঠামোর আয়না হিসাবে ডাটাবেসের অবস্থান, অনুরোধের ধরণ এবং শর্তটি অ্যাক্সেস মঞ্জুর করে।

ডাটাবেস অবস্থান

আপনার বিধিগুলির কাঠামো আপনার ডাটাবেসে আপনি যে ডেটা সংরক্ষণ করেছেন তার কাঠামো অনুসরণ করা উচিত। উদাহরণস্বরূপ, বার্তাগুলির একটি তালিকা সহ একটি চ্যাট অ্যাপে আপনার কাছে এমন ডেটা থাকতে পারে যা দেখতে এটির মতো:

  {
    "messages": {
      "message0": {
        "content": "Hello",
        "timestamp": 1405704370369
      },
      "message1": {
        "content": "Goodbye",
        "timestamp": 1405704395231
      },
      ...
    }
  }

আপনার নিয়মগুলি সেই কাঠামোকে আয়না করা উচিত। যেমন:

  {
    "rules": {
      "messages": {
        "$message": {
          // only messages from the last ten minutes can be read
          ".read": "data.child('timestamp').val() > (now - 600000)",

          // new messages must have a string content and a number timestamp
          ".validate": "newData.hasChildren(['content', 'timestamp']) &&
                        newData.child('content').isString() &&
                        newData.child('timestamp').isNumber()"
        }
      }
    }
  }

উপরের উদাহরণ হিসাবে দেখায়, Realtime Database Rules পাথ বিভাগগুলির সাথে মেলে একটি $location ভেরিয়েবলকে সমর্থন করে। আপনার $ সামনের অংশটি আপনার নিয়মের সাথে পথের সাথে যে কোনও শিশু নোডের সাথে মেলে use

  {
    "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')"
          }
        }
      }
    }
  }

আপনি ধ্রুবক পথের নামগুলির সাথে সমান্তরালে $variable ব্যবহার করতে পারেন।

  {
    "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 }
      }
    }
  }

পদ্ধতি

Realtime Database , তিন ধরণের নিয়ম রয়েছে। এই নিয়মের দুটি ধরণের - read এবং write - আগত অনুরোধের পদ্ধতিতে প্রয়োগ করুন। validate নিয়মের ধরণ ডেটা কাঠামো প্রয়োগ করে এবং ডেটা ফর্ম্যাট এবং সামগ্রীকে বৈধ করে। Rules চালিত .write .validate

ডিফল্টরূপে, যদি এটির অনুমতি দেওয়ার কোনও নিয়ম না থাকে তবে কোনও পথে অ্যাক্সেস অস্বীকার করা হয়।

একটি শর্ত একটি বুলিয়ান অভিব্যক্তি যা নির্ধারণ করে যে একটি নির্দিষ্ট অপারেশন অনুমোদিত বা অস্বীকার করা উচিত। request এবং resource ভেরিয়েবলগুলি সেই শর্তগুলির জন্য প্রসঙ্গ সরবরাহ করে।

request পরিবর্তনশীল

request পরিবর্তনশীলটিতে নিম্নলিখিত ক্ষেত্রগুলি এবং সংশ্লিষ্ট তথ্য অন্তর্ভুক্ত রয়েছে:

request.auth

একটি জেএসএন ওয়েব টোকেন (জেডাব্লুটি) যা Firebase Authentication থেকে প্রমাণীকরণের শংসাপত্রগুলি ধারণ করে। auth টোকেনটিতে স্ট্যান্ডার্ড দাবির একটি সেট রয়েছে এবং Firebase Authentication মাধ্যমে আপনি তৈরি করা কোনও কাস্টম দাবি রয়েছে। Firebase Security Rules এবং Authentication সম্পর্কে আরও জানুন।

request.method

request.method কোনও মানক পদ্ধতি বা কাস্টম পদ্ধতি হতে পারে। সুবিধামত পদ্ধতিগুলি read এবং write লেখার নিয়মগুলি সহজ করার জন্যও বিদ্যমান যা কেবলমাত্র সমস্ত পঠনযোগ্য বা সমস্ত লেখার জন্য কেবলমাত্র স্ট্যান্ডার্ড পদ্ধতির ক্ষেত্রে প্রযোজ্য।

request.params

request.params নির্দিষ্টভাবে request.resource সাথে সম্পর্কিত নয় এমন কোনও ডেটা অন্তর্ভুক্ত রয়েছে es রিসোর্স যা মূল্যায়নের জন্য কার্যকর হতে পারে। অনুশীলনে, এই মানচিত্রটি সমস্ত মানক পদ্ধতির জন্য খালি হওয়া উচিত এবং কাস্টম পদ্ধতির জন্য অ-রিসোর্স ডেটা থাকা উচিত। প্যারাম হিসাবে উপস্থাপিত কী এবং মানগুলির কোনও প্রকারের নাম পরিবর্তন বা সংশোধন না করার জন্য পরিষেবাগুলি অবশ্যই সতর্ক থাকতে হবে।

request.path

request.path হ'ল লক্ষ্য resource পথ। পথটি পরিষেবার সাথে সম্পর্কিত। / -এনকোডেডের মতো নন-ইউআরএল নিরাপদ অক্ষরযুক্ত পাথ বিভাগগুলি।

resource ভেরিয়েবল

resource হ'ল কী-মান জোড়ের মানচিত্র হিসাবে প্রতিনিধিত্ব করা পরিষেবার মধ্যে বর্তমান মান। একটি শর্তের মধ্যে resource রেফারেন্সিংয়ের ফলে পরিষেবা থেকে মানটি বেশিরভাগ পঠিত হবে। এই চেহারাটি রিসোর্সের জন্য কোনও পরিষেবা সম্পর্কিত কোটার বিরুদ্ধে গণনা করবে। get অনুরোধের জন্য, resource কেবল অস্বীকারের কোটার দিকে গণনা করবে।

অপারেটর এবং অপারেটর অগ্রাধিকার

অপারেটরগুলির জন্য একটি রেফারেন্স এবং Cloud Firestore এবং Cloud Storage Rules তাদের সম্পর্কিত অগ্রাধিকার হিসাবে নীচের টেবিলটি ব্যবহার করুন।

নির্বিচারে অভিব্যক্তি a এবং b , একটি ক্ষেত্র f এবং একটি সূচক i ।

একটি শর্ত একটি বুলিয়ান অভিব্যক্তি যা নির্ধারণ করে যে একটি নির্দিষ্ট অপারেশন অনুমোদিত বা অস্বীকার করা উচিত। আপনি নিম্নলিখিত উপায়ে Realtime Database Rules এই শর্তগুলি সংজ্ঞায়িত করতে পারেন।

প্রাক-সংজ্ঞায়িত ভেরিয়েবল

বেশ কয়েকটি সহায়ক, প্রাক-সংজ্ঞায়িত ভেরিয়েবল রয়েছে যা কোনও নিয়ম সংজ্ঞায় অ্যাক্সেস করা যায়। এখানে প্রত্যেকের একটি সংক্ষিপ্ত সংক্ষিপ্তসার রয়েছে:

এই ভেরিয়েবলগুলি আপনার নিয়মের যে কোনও জায়গায় ব্যবহার করা যেতে পারে। উদাহরণস্বরূপ, নীচের সুরক্ষা বিধিগুলি নিশ্চিত করে যে /foo/ নোডে লিখিত ডেটা অবশ্যই 100 টি অক্ষরের চেয়ে কম স্ট্রিং হতে হবে:

{
  "rules": {
    "foo": {
      // /foo is readable by the world
      ".read": true,

      // /foo is writable by the world
      ".write": true,

      // data written to /foo must be a string less than 100 characters
      ".validate": "newData.isString() && newData.val().length < 100"
    }
  }
}

ডেটা-ভিত্তিক নিয়ম

আপনার ডাটাবেসের যে কোনও ডেটা আপনার বিধিগুলিতে ব্যবহার করা যেতে পারে। পূর্বনির্ধারিত ভেরিয়েবল root , data এবং newData ব্যবহার করে আপনি যে কোনও পথ অ্যাক্সেস করতে পারেন যেমন এটি কোনও লেখার ইভেন্টের আগে বা পরে বিদ্যমান থাকবে।

এই উদাহরণটি বিবেচনা করুন, যা লেখার অপারেশনগুলিকে যতক্ষণ না /allow_writes/ নোডের মান true হয় ততক্ষণ মঞ্জুরি দেয়, পিতামাতার নোডের একটি readOnly পতাকা সেট থাকে না এবং নতুন লিখিত ডেটাতে foo নামে একটি শিশু রয়েছে:

".write": "root.child('allow_writes').val() === true &&
          !data.parent().child('readOnly').exists() &&
          newData.child('foo').exists()"

ক্যোয়ারী-ভিত্তিক নিয়ম

যদিও আপনি বিধিগুলি ফিল্টার হিসাবে ব্যবহার করতে পারবেন না, আপনি আপনার বিধিগুলিতে ক্যোয়ারী প্যারামিটারগুলি ব্যবহার করে ডেটা সাবসেটগুলিতে অ্যাক্সেস সীমাবদ্ধ করতে পারেন। query. ক্যোয়ারী পরামিতিগুলির উপর ভিত্তি করে পড়তে বা লিখতে আপনার নিয়মগুলিতে এক্সপ্রেশনগুলি।

উদাহরণস্বরূপ, নিম্নলিখিত ক্যোয়ারী-ভিত্তিক নিয়মটি ব্যবহারকারী-ভিত্তিক সুরক্ষা বিধি এবং ক্যোয়ারী-ভিত্তিক নিয়মগুলি ব্যবহার করে কেবলমাত্র সক্রিয় ব্যবহারকারীর মালিকানাধীন শপিং বেসকেটগুলিতে baskets সংগ্রহের ডেটা অ্যাক্সেসকে সীমাবদ্ধ করতে:

"baskets": {
  ".read": "auth.uid !== null &&
            query.orderByChild === 'owner' &&
            query.equalTo === auth.uid" // restrict basket access to owner of basket
}

নিম্নলিখিত ক্যোয়ারী, যা নিয়মের ক্যোয়ারী প্যারামিটারগুলি অন্তর্ভুক্ত করে, সফল হবে:

db.ref("baskets").orderByChild("owner")
                 .equalTo(auth.currentUser.uid)
                 .on("value", cb)                 // Would succeed

যাইহোক, নিয়মের পরামিতিগুলি অন্তর্ভুক্ত করে না এমন প্রশ্নগুলি PermissionDenied ত্রুটির সাথে ব্যর্থ হবে:

db.ref("baskets").on("value", cb)                 // Would fail with PermissionDenied

কোনও ক্লায়েন্ট রিড অপারেশনের মাধ্যমে কতটা ডেটা ডাউনলোড করে তা সীমাবদ্ধ করতে আপনি ক্যোয়ারী-ভিত্তিক নিয়মগুলিও ব্যবহার করতে পারেন।

উদাহরণস্বরূপ, নিম্নলিখিত নিয়ম সীমাটি অগ্রাধিকার অনুসারে আদেশ অনুসারে একটি ক্যোয়ারির প্রথম 1000 ফলাফলের অ্যাক্সেস পড়তে পারে:

messages: {
  ".read": "query.orderByKey &&
            query.limitToFirst <= 1000"
}

// Example queries:

db.ref("messages").on("value", cb)                // Would fail with PermissionDenied

db.ref("messages").limitToFirst(1000)
                  .on("value", cb)                // Would succeed (default order by key)

নিম্নলিখিত query. Realtime Database Security Rules এক্সপ্রেশনগুলি উপলব্ধ।

অপারেটর

Realtime Database Rules শর্তের বিবৃতিতে ভেরিয়েবলগুলি একত্রিত করতে আপনি ব্যবহার করতে পারেন এমন অনেকগুলি অপারেটরকে সমর্থন করে। রেফারেন্স ডকুমেন্টেশনে অপারেটরগুলির সম্পূর্ণ তালিকা দেখুন।