Cloud Storage জন্য Firebase Security Rules আপনাকে Cloud Storage বালতিতে সঞ্চিত বস্তুর অ্যাক্সেস নিয়ন্ত্রণ করতে দেয়। নমনীয় নিয়ম সিনট্যাক্স আপনাকে আপনার Cloud Storage বালতিতে লেখা থেকে শুরু করে একটি নির্দিষ্ট ফাইলের অপারেশন পর্যন্ত যেকোনো অপারেশন নিয়ন্ত্রণ করার জন্য নিয়ম তৈরি করতে দেয়।
এই নির্দেশিকা সম্পূর্ণ নিয়ম সেট তৈরি করতে 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
।
ওয়াইল্ডকার্ড মেলে
একটি একক ফাইলের দিকে নির্দেশ করা ছাড়াও, 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";
}
অনুক্রমিক তথ্য
যেমনটি আমরা আগেই বলেছি, 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
সত্যে মূল্যায়ন করা হয়, যখন ফাইল "images/users/user:12345/profilePhoto.png" শুধুমাত্র other_condition
ফলাফল সাপেক্ষে .
Cloud Storage Security Rules ক্যাসকেড করে না, এবং নিয়মগুলি শুধুমাত্র তখনই মূল্যায়ন করা হয় যখন অনুরোধের পথটি নির্দিষ্ট নিয়মগুলির সাথে একটি পাথের সাথে মেলে৷
সংস্করণ 1
Firebase Security Rules ডিফল্টরূপে সংস্করণ 1 ব্যবহার করে। সংস্করণ 1-এ, পুনরাবৃত্ত ওয়াইল্ডকার্ডগুলি এক বা একাধিক ফাইলের নাম উপাদানের সাথে মেলে, শূন্য বা একাধিক উপাদান নয়। এইভাবে, match /images/{filenamePrefixWildcard}/{imageFilename=**}
মেলে /images/profilePics/profile.png, কিন্তু /images/badge.png নয়। পরিবর্তে /images/{imagePrefixorFilename=**}
ব্যবহার করুন।
রিকার্সিভ ওয়াইল্ডকার্ড অবশ্যই ম্যাচ স্টেটমেন্টের শেষে আসতে হবে।
আমরা আপনাকে এর আরও শক্তিশালী বৈশিষ্ট্যগুলির জন্য সংস্করণ 2 ব্যবহার করার পরামর্শ দিই।
সংস্করণ 2
Firebase Security Rules সংস্করণ 2-এ, রিকার্সিভ ওয়াইল্ডকার্ড শূন্য বা তার বেশি পাথ আইটেমের সাথে মেলে। এইভাবে, /images/{filenamePrefixWildcard}/{imageFilename=**}
ফাইলের নামের সাথে মিলে যায় /images/profilePics/profile.png এবং /images/badge.png।
rules_version = '2';
আপনার নিরাপত্তা নিয়মের শীর্ষে:
rules_version = '2';
service cloud.storage {
match /b/{bucket}/o {
...
}
}
প্রতি ম্যাচ স্টেটমেন্টে আপনার কাছে সর্বাধিক একটি রিকারসিভ ওয়াইল্ডকার্ড থাকতে পারে, কিন্তু সংস্করণ 2-এ, আপনি ম্যাচ স্টেটমেন্টের যেকোনো জায়গায় এই ওয়াইল্ডকার্ড রাখতে পারেন। যেমন:
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
বিভক্ত করা যেতে পারে।
একটি 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 (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 অন্বেষণ করতে পারেন: