ক্লাউড স্টোরেজ ভাষার জন্য ফায়ারবেস নিরাপত্তা নিয়মের মূল সিনট্যাক্স শিখুন

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

দ্রষ্টব্য: Cloud Storage বাকেটগুলিতে শুধুমাত্র ফাইল থাকে, ডিরেক্টরি থাকে না। এই পৃষ্ঠায় আপনি ফাইলের নামে স্ল্যাশ / দেখতে পাবেন, যেমন /images/profilePhoto.png , যা থেকে মনে হতে পারে যে একটি বাকেটের মধ্যে ডিরেক্টরি এবং সাব-ডিরেক্টরির একটি স্তরবিন্যাস রয়েছে। তবে, ফাইলের নামে স্ল্যাশসহ প্রিফিক্স অন্তর্ভুক্ত করা যেতে পারে, যা আপনাকে এমন স্বতন্ত্র ফাইলের নাম নির্ধারণ করার সুযোগ দেয় যা ফাইল সিস্টেমে ব্যবহৃত সম্পূর্ণ ডিরেক্টরি পাথের মতো দেখায়।

এই নির্দেশিকায় সম্পূর্ণ রুলসেট তৈরি করার জন্য Cloud Storage Security Rules মৌলিক সিনট্যাক্স এবং কাঠামো বর্ণনা করা হয়েছে।

পরিষেবা এবং ডাটাবেস ঘোষণা

Cloud Storage জন্য Firebase Security Rules সর্বদা নিম্নলিখিত ঘোষণা দিয়ে শুরু হয়:

service firebase.storage {
    // ...
}

service firebase.storage ডিক্লারেশনটি নিয়মগুলোকে Cloud Storage মধ্যে সীমাবদ্ধ রাখে, ফলে Cloud Storage Security Rules এবং Cloud Firestore মতো অন্যান্য প্রোডাক্টের নিয়মের মধ্যে কোনো সংঘাত হয় না।

মৌলিক পঠন/লিখন নিয়মাবলী

মৌলিক নিয়মগুলির মধ্যে রয়েছে Cloud Storage বাকেট শনাক্তকারী একটি match স্টেটমেন্ট, একটি ফাইলের নাম নির্দিষ্টকারী একটি ম্যাচ স্টেটমেন্ট, এবং নির্দিষ্ট ডেটা কখন পড়া যাবে তার বিশদ বিবরণ প্রদানকারী একটি allow এক্সপ্রেশন। allow এক্সপ্রেশনগুলি সংশ্লিষ্ট অ্যাক্সেস পদ্ধতি (যেমন, রিড, রাইট) এবং যে শর্তগুলির অধীনে অ্যাক্সেস অনুমোদিত বা প্রত্যাখ্যাত হবে তা নির্দিষ্ট করে।

আপনার ডিফল্ট রুলসেটে, প্রথম match স্টেটমেন্টটি একটি {bucket} ওয়াইল্ডকার্ড এক্সপ্রেশন ব্যবহার করে বোঝায় যে নিয়মগুলো আপনার প্রোজেক্টের সমস্ত বাকেটের জন্য প্রযোজ্য। আমরা পরবর্তী বিভাগে ওয়াইল্ডকার্ড ম্যাচের ধারণাটি নিয়ে আরও আলোচনা করব।

service firebase.storage {
  // The {bucket} wildcard indicates we match files in all Cloud Storage buckets
  match /b/{bucket}/o {
    // Match filename
    match /filename {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

সমস্ত ম্যাচ স্টেটমেন্ট ফাইল নির্দেশ করে। একটি ম্যাচ স্টেটমেন্ট কোনো নির্দিষ্ট ফাইলকে নির্দেশ করতে পারে, যেমন match /images/profilePhoto.png ।

ম্যাচ ওয়াইল্ডকার্ড

একটি নির্দিষ্ট ফাইল নির্দেশ করার পাশাপাশি, Security Rules ওয়াইল্ডকার্ড ব্যবহার করে নামের মধ্যে একটি নির্দিষ্ট স্ট্রিং প্রিফিক্স থাকা যেকোনো ফাইলকে নির্দেশ করতে পারে, যার মধ্যে স্ল্যাশও অন্তর্ভুক্ত থাকতে পারে, যেমন match /images/{imageId} ।

উপরের উদাহরণে, ম্যাচ স্টেটমেন্টে {imageId} ওয়াইল্ডকার্ড সিনট্যাক্স ব্যবহার করা হয়েছে। এর মানে হলো, এই নিয়মটি এমন যেকোনো ফাইলের ক্ষেত্রে প্রযোজ্য যার নামের শুরুতে /images/ আছে, যেমন /images/profilePhoto.png বা /images/croppedProfilePhoto.png । যখন ম্যাচ স্টেটমেন্টের allow এক্সপ্রেশনগুলো মূল্যায়ন করা হয়, তখন imageId ভেরিয়েবলটি ইমেজ ফাইলের নামে পরিণত হবে, যেমন profilePhoto.png বা croppedProfilePhoto.png ।

ফাইলের নাম বা পাথের অনুমোদন দেওয়ার জন্য match ভেতর থেকে একটি ওয়াইল্ডকার্ড ভেরিয়েবলকে রেফারেন্স করা যেতে পারে:

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

দ্রষ্টব্য: ব্যবহারকারীরা শুধুমাত্র সেই ফাইলগুলিই অ্যাক্সেস করতে পারবেন যেগুলি আপনার Firebase Security Rules বিশেষভাবে অনুমোদিত। উদাহরণস্বরূপ, উপরে দেখানো নিয়মগুলি শুধুমাত্র সেই ফাইলগুলিকে অ্যাক্সেস করার অনুমতি দেয় যাদের নামের শুরুতে /images/ থাকে; ফলস্বরূপ, এগুলি ভিন্ন ফাইলনেম প্রিফিক্সযুক্ত ফাইলগুলিকে অ্যাক্সেস করতে বাধা দেয়।

শ্রেণিবদ্ধ ডেটা

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

এমন একগুচ্ছ ফাইলের কথা ভাবুন, যেগুলোর নাম সবই /images/ দিয়ে শুরু হয়। Firebase Security Rules শুধুমাত্র মিলে যাওয়া ফাইলের নামেই প্রযোজ্য হয়, তাই /images/ স্টেমের জন্য সংজ্ঞায়িত অ্যাক্সেস কন্ট্রোলগুলো /mp3s/ স্টেমের ক্ষেত্রে প্রযোজ্য হয় না। এর পরিবর্তে, ভিন্ন ভিন্ন ফাইলের নামের প্যাটার্ন মেলানোর জন্য সুস্পষ্ট নিয়ম লিখুন:

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      allow read, write: if <condition>;
    }

    // Explicitly define rules for the 'mp3s' pattern
    match /mp3s/{mp3Id} {
      allow read, write: if <condition>;
    }
  }
}

match স্টেটমেন্ট নেস্ট করার সময়, ভেতরের match স্টেটমেন্টের পাথ সর্বদা বাইরের match স্টেটমেন্টের পাথের সাথে যুক্ত হয়। তাই, নিম্নলিখিত দুটি রুলসেট সমতুল্য:

service firebase.storage {
  match /b/{bucket}/o {
    match /images {
      // Exact match for "images/profilePhoto.png"
      match /profilePhoto.png {
        allow write: if <condition>;
      }
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    // Exact match for "images/profilePhoto.png"
    match /images/profilePhoto.png {
      allow write: if <condition>;
      }
  }
}

পুনরাবৃত্তিমূলক ম্যাচ ওয়াইল্ডকার্ড

ফাইলের নামের শেষে স্ট্রিং ম্যাচ করে ফেরত দেয় এমন ওয়াইল্ডকার্ড ছাড়াও, আরও জটিল ম্যাচিংয়ের জন্য ওয়াইল্ডকার্ড নামের সাথে =** যোগ করে একাধিক সেগমেন্টের ওয়াইল্ডকার্ড ঘোষণা করা যেতে পারে, যেমন {path=**} :

// Partial match for files that start with "images"
match /images {

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

যদি একাধিক নিয়ম একটি ফাইলের সাথে মিলে যায়, তাহলে ফলাফলটি হবে সমস্ত নিয়মের মূল্যায়নের ফলাফলের OR । অর্থাৎ, ফাইলটির সাথে মিলে যাওয়া যেকোনো নিয়মের মূল্যায়ন যদি ' true হয়, তাহলে ফলাফলটিও true হবে।

উপরের নিয়মগুলো অনুসারে, 'images/profilePhoto.png' ফাইলটি পড়া যাবে যদি condition অথবা other_condition যেকোনো একটির মান 'true' হয়, অপরদিকে 'images/users/user:12345/profilePhoto.png' ফাইলটি শুধুমাত্র other_condition এর ফলাফলের উপর নির্ভরশীল।

Cloud Storage Security Rules ক্রমান্বয়ে প্রয়োগ হয় না, এবং নিয়মগুলো কেবল তখনই মূল্যায়ন করা হয় যখন অনুরোধের পাথটি নির্দিষ্ট নিয়মযুক্ত কোনো পাথের সাথে মিলে যায়।

সংস্করণ ১

Firebase Security Rules ডিফল্টরূপে ভার্সন ১ ব্যবহার করে। ভার্সন ১-এ, রিকার্সিভ ওয়াইল্ডকার্ড এক বা একাধিক ফাইলের নামের উপাদানের সাথে মেলে, শূন্য বা তার বেশি উপাদানের সাথে নয়। সুতরাং, match /images/{filenamePrefixWildcard}/{imageFilename=**} এই ধরনের ম্যাচ `/images/profilePics/profile.png`-এর মতো ফাইলের নামের সাথে মেলে, কিন্তু `/images/badge.png`-এর সাথে মেলে না। এর পরিবর্তে /images/{imagePrefixorFilename=**} ব্যবহার করুন।

রিকার্সিভ ওয়াইল্ডকার্ড অবশ্যই ম্যাচ স্টেটমেন্টের শেষে আসতে হবে।

এর আরও শক্তিশালী বৈশিষ্ট্যগুলোর জন্য আমরা আপনাকে সংস্করণ ২ ব্যবহার করার পরামর্শ দিই।

সংস্করণ ২

Firebase Security Rules এর ভার্সন ২-এ, রিকার্সিভ ওয়াইল্ডকার্ড শূন্য বা তার বেশি পাথ আইটেমকে ম্যাচ করে। যেমন, /images/{filenamePrefixWildcard}/{imageFilename=**} এই ওয়াইল্ডকার্ডটি /images/profilePics/profile.png এবং /images/badge.png ফাইলনেমগুলোকে ম্যাচ করে।

আপনার নিরাপত্তা নিয়মের শীর্ষে rules_version = '2'; যোগ করে আপনাকে অবশ্যই সংস্করণ ২ চালু করতে হবে:

rules_version = '2';
service cloud.storage {
  match /b/{bucket}/o {
   ...
 }
}

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

rules_version = '2';
service firebase.storage {
 match /b/{bucket}/o {
   // Matches any file in a songs "subdirectory" under the
   // top level of your Cloud Storage bucket.
   match /{prefixSegment=**}/songs/{mp3filenames} {
     allow read, write: if <condition>;
   }
  }
}

দানাদার কার্যক্রম

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

একটি read অপারেশনকে get এবং list এ ভাগ করা যায়।

দ্রষ্টব্য: Security Rules list অপারেশন এবং ফলস্বরূপ Cloud Storage লিস্ট এপিআই শুধুমাত্র সেইসব প্রোজেক্টে উপলব্ধ, যেগুলি Security Rules ভার্সন ২ ব্যবহার করে।

একটি write রুলকে create , update এবং delete এ ভাগ করা যায়:

service firebase.storage {
  match /b/{bucket}/o {
    // A read rule can be divided into read and list rules
    match /images/{imageId} {
      // Applies to single file read requests
      allow get: if <condition>;
      // Applies to list and listAll requests (Security Rules Version 2)
      allow list: if <condition>;

    // A write rule can be divided into create, update, and delete rules
    match /images/{imageId} {
      // Applies to writes to file contents
      allow create: if <condition>;

      // Applies to updates to (pre-existing) file metadata
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
 }
}

ওভারল্যাপিং ম্যাচ স্টেটমেন্ট

একটি ফাইলের নাম একাধিক match স্টেটমেন্টের সাথে মিলে যেতে পারে। যদি একাধিক allow এক্সপ্রেশন একটি রিকোয়েস্টের সাথে মিলে যায়, তবে শর্তগুলোর মধ্যে যেকোনো একটি true হলে অ্যাক্সেসের অনুমতি দেওয়া হয়।

service firebase.storage {
  match b/{bucket}/o {
    // Matches file names directly inside of '/images/'.
    match /images/{imageId} {
      allow read, write: if false;
    }

    // Matches file names anywhere under `/images/`
    match /images/{imageId=**} {
      allow read, write: if true;
    }
  }
}

উপরের উদাহরণে, যেসব ফাইলের নাম /images/ দিয়ে শুরু হয়, সেগুলোতে সমস্ত রিড এবং রাইট অনুমোদিত, কারণ দ্বিতীয় নিয়মটি সর্বদা true , এমনকি যখন প্রথম নিয়মটি false হয়।

নিয়মগুলো ফিল্টার নয়

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

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

service firebase.storage {
  match /b/{bucket}/o {
    // Allow the client to read files with contentType 'image/png'
    match /aFileNamePrefix/{aFileName} {
      allow read: if resource.contentType == 'image/png';
    }
  }
}

প্রত্যাখ্যাত : এই নিয়মটি নিম্নলিখিত অনুরোধটি প্রত্যাখ্যান করছে কারণ ফলাফল সেটে এমন ফাইল অন্তর্ভুক্ত থাকতে পারে যেগুলির contentType image/png নয় :

ওয়েব

filesRef = storage.ref().child("aFilenamePrefix");

filesRef.listAll()
    .then(function(result) {
      console.log("Success: ", result.items);
    })
});

Cloud Storage Security Rules প্রতিটি কোয়েরিকে তার সম্ভাব্য ফলাফলের নিরিখে মূল্যায়ন করে এবং যদি এটি এমন কোনো ফাইল ফেরত দিতে পারে যা পড়ার অনুমতি ক্লায়েন্টের নেই, তাহলে অনুরোধটি ব্যর্থ করে দেয়। অ্যাক্সেসের অনুরোধগুলোকে অবশ্যই আপনার নিয়ম দ্বারা নির্ধারিত সীমাবদ্ধতা মেনে চলতে হবে।

পরবর্তী পদক্ষেপ

Cloud Storage জন্য Firebase Security Rules সম্পর্কে আপনার জ্ঞান আরও গভীর করতে পারেন:

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

• সাধারণ নিরাপত্তা ব্যবহারের ক্ষেত্রসমূহ এবং সেগুলোকে সমাধানকারী Firebase Security Rules সংজ্ঞাগুলো পর্যালোচনা করুন।

আপনি Cloud Storage জন্য নির্দিষ্ট Firebase Security Rules ব্যবহারের ক্ষেত্রগুলো অন্বেষণ করতে পারেন: