Firebase Storage: این چیست، آپلود فایل و ذخیره‌سازی در ابر

Firebase Storage چیست و چگونه کار می‌کند

Firebase Storage — یک ذخیره‌سازی شئ‌گرای ابری است که بر پایه Google Cloud Storage ساخته شده و SDK را برای پلتفرم‌های Android، iOS و وب فراهم می‌کند. هر فایل به صورت یک شئ در یک سطل Google Cloud ذخیره می‌شود و با یک مسیر مانند سیستم فایلی آدرس‌دهی می‌شود: gs://bucket-name/path/to/file.jpg. اندازه یک فایل می‌تواند به ۵ TB برسد که امکان ذخیره هر گونه داده رسانه‌ای را بدون فشردگی قبلی فراهم می‌کند.

معماری Firebase Storage از مدل مرجعی ارتباطات (gsutil references) استفاده می‌کند نه سلسله‌مراتب پوشه کلاسیک، هرچند SDK برای راحتی توسعه‌دهنده با پوشه‌ها یک رابط دارد. فیزیکی، همه شئ‌ها در یک فضای نام مسطح سطل ذخیره می‌شوند و پوشه‌های مجازی با پیشوندهای مسیر ایجاد می‌شوند. این عملکرد جستجوی خطی را بدون توجه به تعداد فایل‌ها تضمین می‌کند.

مزیت کلیدی Firebase Storage نسبت به استفاده مستقیم از Google Cloud Storage یکپارچگی داخلی با Firebase Authentication و Security Rules است. توسعه‌دهنده نیازی به تنظیم نقش‌های IAM جداگانه و حساب‌های خدماتی ندارد: قوانین دسترسی به زبان اعلانی مانند Firebase Realtime Database Rules نوشته می‌شوند و در هر درخواست به صورت خودکار اعمال می‌شوند.

ساختار سطل و مسیرهای فایل‌ها

سطل Firebase Storage به صورت خودکار با اتصال سرویس در کنسول Firebase ایجاد می‌شود. مسیر فایل بر اساس اصل /نام_پوشه/نام_فایل ساخته می‌شود و می‌تواند سطوح تو در تو داشته باشد. برای جداسازی داده‌ها بین کاربران، سازماندهی مسیرها به صورت /users/{userId}/images/{imageId}.jpg توصیه می‌شود. چنین ساختاری نوشتن قوانین امنیتی را ساده می‌کند چون مسیر شامل شناسه مالک است.

مهم است بدانید که Firebase Storage یک پایگاه داده ارتباطی یا سرور فایل در مفهوم کلاسیک نیست. این یک ذخیره‌سازی شئ‌گرای است که برای عملیات خواندن و نوشتن کامل فایل‌ها بهینه‌سازی شده است. به‌روزرسانی بخشی از فایل امکان‌پذیر نیست: در آپلود مجدد با همان مسیر، شئ قدیمی با شئ جدید جایگزین می‌شود. برای ذخیره داده‌های کوچک ساختاریافته از Firebase Realtime Database یا Cloud Firestore استفاده کنید.

تعرفه و محدودیت‌های Firebase Storage

قیمت‌گذاری Firebase Storage به حجم داده‌های ذخیره‌شده و تعداد عملیات بستگی دارد. تعرفه رایگان (Spark) شامل ۵ گیگابایت ذخیره، ۲۰٬۰۰۰ عملیات نوشتن و ۵۰٬۰۰۰ عملیات خواندن در روز است. تعرفه پرداختی (Blaze) بر اساس مصرف واقعی محاسبه می‌شود: $۰.۰۲۶ به ازای هر گیگابایت داده‌های ذخیره‌شده، $۰.۰۵ به ازای ۱۰٬۰۰۰ عملیات نوشتن و $۰.۰۰۴ به ازای ۱۰٬۰۰۰ عملیات خواندن. علاوه بر این برای ترافیک خروجی هزینه دریافت می‌شود.

برای اکثر اپلیکیشن‌های موبایل با چند هزار کاربر، محدودیت رایگان در مرحله نمونه‌سازی و آزمایش کافی است. هنگام مقیاس‌پذیری به صدها هزار کاربر، هزینه‌های Storage با رویکرد بهینه آپلود و ذخیره‌سازی در طرف مشتری به ندرت از $۵۰–$۱۰۰ در ماه تجاوز می‌کند.

چگونه فایل‌ها را در Firebase Storage آپلود کنیم

آپلود فایل در Firebase Storage از طریق روش مناسب SDK انجام می‌شود که مسیر ذخیره و داده‌های فایل (ماتریس بایت‌ها، URI، جریان یا Bitmap) را می‌پذیرد. SDK به صورت خودکار اتصال را مدیریت می‌کند، فایل را در اندازه بزرگ به بخش‌هایی تقسیم می‌کند و فراخوان‌هایی برای پیگیری پیشرفت فراهم می‌کند. آپلود مستقیماً از دستگاه کلاینت به Google Cloud انجام می‌شود و سرور شما را دور می‌زند که بار زیرساخت خود را کاهش می‌دهد.

برای Android Firebase Storage SDK از کلاس‌های StorageReference و UploadTask استفاده می‌کند. StorageReference از مسیر ریشه از طریق Firebase.storage.reference ایجاد می‌شود و به یک فایل مشخص در سطل اشاره می‌کند. UploadTask شنوندگان پیشرفت، توقف و تکمیل را برمی‌گرداند. در صورت اختلال اتصال، UploadTask به صورت خودکار آپلود را از آخرین بایت موفق ادامه می‌دهد — این رفتار آپلود قابل ازسرگیری (resumable upload) نامیده می‌شود.

فراداده فایل (Content-Type، فیلدهای سفارشی) به صورت یک شئ جداگانه SettableMetadata در شروع آپلود ارسال می‌شود. تنظیم درست Content-Type برای نمایش درست فایل‌ها در مرورگر و عملکرد ذخیره‌سازی CDN بسیار مهم است. Firebase Storage از تمام انواع MIME استاندارد پشتیبانی می‌کند: image/jpeg، image/png، video/mp4، application/pdf و سایر.

مدیریت فراداده در حین آپلود

فراداده فایل شامل فیلدهای سیستم (Content-Type، Cache-Control، Content-Disposition) و جفت‌های کلید-مقدار سفارشی (customMetadata) است. فیلدهای سیستم سربرگ‌های HTTP را در حین دانلود کنترل می‌کنند. مثلاً Cache-Control: public, max-age=31536000 ذخیره‌سازی پاسخ را برای یک سال فعال می‌کند که تعداد دانلودهای مکرر همان فایل را به طور قابل توجهی کاهش می‌دهد و در پهنای باند صرفه‌جویی می‌کند.

فراداده سفارشی برای ارسال اطلاعات اضافی درباره فایل بدون ایجاد یک مجموعه جداگانه در Firestore مناسب است. مثلاً در فیلد uploadedBy می‌توان userId کاربری که فایل را آپلود کرده ذخیره کرد که اجرای گالری‌های با محتوای نویسنده را ساده می‌کند. فراداده سفارشی توسط Security Rules به صورت جداگانه محافظت نمی‌شود — دسترسی به آنها توسط همان قوانینی که به خود فایل تنظیم می‌شود.

آپلود چندگانه و پردازش دسته‌ای

در صورت نیاز به آپلود چندین فایل به صورت همزمان (مثلاً عکس‌هایی از گالری)، اجرای مستقیم UploadTask‌های مستقل به صورت موازی بدون محدودیت توصیه نمی‌شود. در دستگاه‌های موبایل، آپلود موازی بیش از ۳–۵ فایل منجر به اضافه‌بار پشته شبکه و مهلت زمانی می‌شود. استراتژی بهینه استفاده از حد همزمانی ۳ یا آپلود ترتیبی با نمایش نوار پیشرفت کلی است.

برای پردازش سرور پس از آپلود (تولید تصویر بندانگشتی، فشردگی، مدیریت محتوا) از تریگر Firebase Cloud Functions استفاده کنید: functions.storage.object().onFinalize(). این تابع پس از تکمیل آپلود هر فایل به صورت خودکار فراخوانده می‌شود و می‌تواند یک کپی پردازش‌شده را در مسیر دیگری ذخیره کند. جزئیات بیشتر در بخش سناریوهای معمولی استفاده.

دانلود فایل‌ها و مدیریت لینک‌ها

Firebase Storage از دو روش دانلود پشتیبانی می‌کند: دانلود مستقیم از طریق SDK با دریافت ماتریس بایت‌ها یا فایل محلی، و دریافت download URL مستقیم برای دسترسی از طریق HTTP. URL مستقیم را می‌توان برای نمایش تصاویر در ImageView، در WebView یا برای ارائه لینک به کاربر استفاده کرد. Download URL با یک توکن امنیتی تولید می‌شود که می‌توان آن را در کنسول Firebase لغو کرد.

روش storageReference.downloadUrl URL را در قالب https://firebasestorage.googleapis.com/v0/b/{bucket}/o/{path}?alt=media&token={token} برمی‌گرداند. توکن امنیتی به صورت خودکار در زمان تولید در URL قرار می‌گیرد، بنابراین لینک را می‌توان بدون خطر دسترسی غیرمجاز به اشخاص ثالث (مثلاً در پیام‌رسان) ارسال کرد. اما اگر توکن به خطر افتاده است، می‌توان آن را از طریق کنسول Firebase در بخش Storage لغو کرد — پس از آن همه لینک‌های با این توکن از کار می‌افتند.

برای ذخیره‌سازی فایل‌های دانلودشده در طرف کلاینت از ذخیره‌سازی محلی و مکانیزم ETag یا هش MD5 استفاده کنید. Firebase Storage در پاسخ به درخواست فایل، سربرگ HTTP ETag را برمی‌گرداند که می‌توان آن را با مقدار ذخیره‌شده محلی مقایسه کرد و از دانلود مجدد فایل‌های تغییرنکرده جلوگیری کرد. این به ویژه برای محتوای رسانه‌ای مفید است: آواتارها، کاور، پیش‌نمایش‌ها — فایل‌هایی که به ندرت به‌روز می‌شوند اما مکرراً درخواست می‌شوند.

لینک‌های مستقیم download URL و امنیت آنها

Download URL با توکن راه اصلی ارائه دسترسی به فایل‌ها برای کاربران تأییدنشده است (مثلاً برای نمایش تصویر در فید اخبار). توکن یکبار تولید می‌شود و تا لغو تغییر نمی‌کند، بنابراین URL را می‌توان در پایگاه داده ذخیره کرد (مثلاً در کنار فیلد avatarUrl در Firestore). هنگام تغییر آواتار، فایل قدیمی حذف می‌شود و URL جدید تولید و ذخیره می‌شود.

مهم است به یاد داشته باشید: وجود download URL Security Rules را لغو نمی‌کند. اگر قانون خواندن فایل را ممنوع کند، روش downloadUrl خطای Permission Denied را برمی‌گرداند. این به این معنی است که حتی با دانستن مسیر درست فایل، یک مشتری تأییدنشده نمی‌تواند لینک را به دست آورد. پس از دریافت URL، دسترسی به فایل از طریق HTTP و بدون دور زدن Security Rules انجام می‌شود — بنابراین توکن تنها محافظت لینک دانلود است.

ذخیره‌سازی و کار با ETag

HTTP ETag — شناسه‌گر نسخه فایل است که با هر تغییر محتوا تغییر می‌کند. Firebase Storage به صورت خودکار ETag را در پاسخ به درخواست GET برمی‌گرداند. اپلیکیشن کلاینت می‌تواند ETag را در ذخیره محلی ذخیره کرده و در درخواست مجدد سربرگ If-None-Match: {etag} را ارسال کند. اگر فایل تغییر نکرده باشد، سرور وضعیت 304 Not Modified را بدون انتقال داده برمی‌گرداند.

برای پیاده‌سازی ذخیره‌سازی هوشمند در اپلیکیشن موبایل از ترکیب سیستم فایل محلی و پایگاه داده استفاده کنید (مثلاً Room برای ذخیره جفت‌های مسیر-ETag). هنگام دانلود فایل، ETag را از پایگاه داده بررسی کنید: اگر با سرور مطابقت داشت، از نسخه محلی استفاده کنید. چنین رویکردی ترافیک را برای فایل‌های ماندگار مولتی‌مدیا به میزان ۶۰–۸۰% کاهش می‌دهد و بارگیری صفحات با گالری‌ها را سریع می‌کند.

قوانین امنیتی برای Firebase Storage

Security Rules — یک زبان اعلانی برای محدود کردن دسترسی به فایل‌ها در Firebase Storage است که در طرف سرور Firebase اجرا می‌شود. هر قانون به یک مسیر در سطل متصل شده و شرایطی را تعیین می‌کند که در آن عملیات خواندن (read) یا نوشتن (write) مجاز است. قوانین قبل از هر درخواست بررسی شده و توسط کد کلاینت قابل دور زدن نیستند. این تنها خط محافظت از داده‌ها در برابر دسترسی غیرمجاز است.

قاعده اساسی — دسترسی تنها برای کاربران تأییدشده: allow read, write: if request.auth != null. چنین قاعده‌ای تضمین می‌کند که فقط کاربران واردشده به سیستم می‌توانند فایل‌ها را بخوانند و بنویسند. برای تنظیم دقیق‌تر، متغیر request.auth.uid استفاده می‌شود که شناسه کاربر فعلی را نگه می‌دارد. با مقایسه uid با بخشی از مسیر فایل، می‌توان یک ذخیره جداگانه برای هر کاربر ایجاد کرد.

مهم: Security Rules یک مکانیزم اعتبارسنجی محتوا نیستند. اگر نیاز به بررسی نوع فایل، اندازه یا وجود کد مخرب دارید، از قانون request.resource استفاده کنید که فراداده فایل آپلودی را شامل می‌شود. ویژگی‌های request.resource.size (اندازه فایل)، request.resource.contentType (نوع MIME) و request.resource.md5Hash (مجموع کنترلی) قابل دسترسی هستند. اما بررسی کامل محتوا در طرف سرور از طریق Cloud Functions انجام می‌شود.

نمونه قوانین برای محتوای کاربری

پیکربندی معمولی برای یک اپلیکیشن با آواتارهای کاربری و گالری به شکل زیر است. کاربر فقط می‌تواند در پوشه خود /users/{userId}/ بنویسد، اما می‌تواند هر فایلی را در این پوشه بخواند (گالری عمومی). اندازه فایل به ۵ مگابایت محدود شده و نوع فقط تصاویر است. چنین ترکیبی از قوانین ۸۰% سناریوهای استفاده از Firebase Storage را در اپلیکیشن‌های اجتماعی و UGC پوشش می‌دهد.

نصیحت امنیتی: هرگز از قاعده allow read, write: if true برای کل سطل استفاده نکنید. این دسترسی نوشتن را به هر کسی که projectId شما را بداند باز می‌کند. در سال ۲۰۲۵، حملات به سطل‌های محافظت‌نشده Firebase افزایش یافت و مهاجمان از دسترسی باز برای ذخیره محتوای غیرقانونی استفاده کردند. همیشه با کمترین مجوزهای لازم شروع کنید و فقط در صورت نیاز واضح آنها را گسترش دهید.

اعتبارسنجی محتوا از طریق Cloud Functions

Cloud Functions تریگر functions.storage.object().onFinalize() امکان اعتبارسنجی محتوا را پس از آپلود فراهم می‌کند. اگر فایل از اعتبارسنجی عبور نکند (مثلاً حاوی ویروس باشد یا قوانین پلتفرم را نقض کند)، تابع می‌تواند فایل را حذف کرده و به کاربر اطلاع دهد. این تنها راه بررسی محتوای واقعی است، چون Security Rules فقط فراداده (اندازه و نوع MIME) را می‌بینند، نه داده‌های دودویی.

نمونه اعتبارسنجی: یک تابع در Node.js فایل آپلودی را در یک پوشه موقت دانلود می‌کند، آن را از طریق یک آشکارساز ضد ویروس (مثلاً ClamAV) عبور می‌دهد، و اگر تهدیدی یافت شود — فایل را حذف کرده و رویداد را در Firebase Crashlytics ثبت می‌کند. زمان اجرای تابع به ۵۴۰ ثانیه محدود شده است که برای بررسی فایل‌های تا حجم ۵۰ مگابایت کافی است.

نمونه کد برای Firebase Storage در Kotlin

نمونه‌های عملی یکپارچگی Firebase Storage را در اپلیکیشن Android به زبان Kotlin بررسی می‌کنیم. کد از کلاس‌های استاندارد Firebase SDK استفاده کرده و آپلود تصویر از گالری دستگاه، دانلود فایل با پیگیری پیشرفت و دریافت download URL را نشان می‌دهد. همه نمونه‌ها با حساب مدیریت خطا و توقف وظایف در صورت از دست رفتن اتصال انجام شده‌اند.

قبل از استفاده از کد، اطمینان حاصل کنید که در فایل build.gradle وابستگی implementation(platform("com.google.firebase:firebase-bom:33.0.0")) و implementation("com.google.firebase:firebase-storage") اضافه شده است. Firebase BOM به صورت خودکار نسخه‌های سازگار تمام SDK را انتخاب می‌کند که تعارضات نسخه را از بین می‌برد.

آپلود تصویر از گالری

نمونه اول — آپلود فایلی که توسط کاربر از طریق Intent ACTION_GET_CONTENT انتخاب شده. URI فایل به Firebase Storage SDK ارسال می‌شود که به صورت مستقل داده‌ها را از این URI می‌خواند. روش putFile URI را پذیرفته و UploadTask را برمی‌گرداند — شئ‌ای که از طریق آن می‌توان پیشرفت را پیگیری کرد، آن را متوقف و از سر گرفت.

val storageRef = Firebase.storage.reference
val imageRef = storageRef.child(
    "users/${auth.uid}/profile.jpg"
)

val metadata = SettableMetadata().apply {
    contentType = "image/jpeg"
    customMetadata = mapOf(
        "uploadedBy" to auth.uid!!
    )
}

imageRef.putFile(imageUri, metadata)
    .addOnSuccessListener {
        Log.d("Storage", "فایل آپلود شد")
    }
    .addOnFailureListener { e ->
        Log.e("Storage", "خطا: ${e.message}")
    }

در نمونه بالا متغیر storageRef یک ارجاع ریشه به سطل پروژه است. روش child یک رشته مسیر را پذیرفته و StorageReference را برمی‌گرداند که به یک فایل مشخص اشاره می‌کند. اگر فایلی در مسیر مشخص وجود داشته باشد، روی آن بازنویسی می‌شود. فراداده contentType و customMetadata از طریق شئ SettableMetadata که به درخواست putFile وصل می‌شود ارسال می‌شوند.

دانلود فایل با پیشرفت

نمونه دوم دانلود فایل را با دریافت ماتریس بایت‌ها برای نمایش در ImageView نشان می‌دهد. روش getBytes(<maxSize>) کل فایل را در حافظه بارگیری می‌کند. برای فایل‌های بزرگتر از ۱۰ مگابایت از getFile(<localUri>) استفاده کنید — آن محتوا را مستقیماً در فایل محلی ذخیره می‌کند بدون نگهداری در حافظه RAM که از OutOfMemoryError جلوگیری می‌کند.

val islandRef = storageRef.child("images/island.jpg")

val ONE_MEGABYTE: Long = 1024 * 1024
islandRef.getBytes(ONE_MEGABYTE)
    .addOnSuccessListener { bytes ->
        imageView.setImageBitmap(
            BitmapFactory.decodeByteArray(
                bytes, 0, bytes.size
            )
        )
    }
    .addOnFailureListener { e ->
        Log.e("Storage", "آپلود انجام نشد: ${e.message}")
    }

برای دریافت download URL (مثلاً برای ذخیره لینک در Firestore) از روش downloadUrl استفاده می‌شود:

islandRef.downloadUrl.addOnSuccessListener { uri ->
    Log.d("Storage", "Download URL: $uri")
    // uri.toString() را در Firestore ذخیره کن
}

نصیحت: downloadUrl یکبار تولید می‌شود و تا لغو پایدار است. آن را در اولین آپلود در پایگاه داده ذخیره کنید، نه اینکه هر بار هنگام نمایش فایل درخواست کنید. این تعداد درخواست‌ها به Firebase Storage را کاهش می‌دهد و کار UI را سریع می‌کند.

سناریوهای معمولی استفاده Firebase Storage

Firebase Storage در اپلیکیشن‌های موبایل برای ذخیره هر گونه فایل کاربری و سیستمی استفاده می‌شود. مکررترین سناریوها — آواتارها و عکس‌های پروفایل، تصاویر در فید محتوا، فایل‌های ویدئو و صدا، اسناد (PDF، DOCX) برای تبادل بین کاربران، و همچنین پشتیبان‌گیری حجم کوچک داده‌ها. در همه این موارد Storage به عنوان یک ذخیره فایل تخصصی در ترکیب با Firestore برای ذخیره فراداده و لینک‌ها عمل می‌کند.

اپلیکیشن‌های اجتماعی — مکررترین مورد استفاده. هر کاربر آواتار، عکس‌های پست و فایل‌های رسانه‌ای آپلود می‌کند. ساختار مسیرهای /users/{uid}/posts/{postId}/image.jpg امکان جداسازی داده‌ها و ساده‌سازی Security Rules را فراهم می‌کند. هنگام حذف کاربر، Cloud Function می‌تواند از همه پوشه‌های کاربر عبور کرده و ذخیره را پاک کند. طبق وبلاگ Firebase (۲۰۲۵)، چنین الگویی در ۷۰% پروژه‌های تولیدی روی Firebase استفاده می‌شود.

اپلیکیشن‌های تجارت الکترونیک از Firebase Storage برای ذخیره عکس‌های محصولات، کاتالوگ‌ها و فایل‌های PDF با دستورالعمل‌ها استفاده می‌کنند. در این مورد دسترسی به فایل‌ها معمولاً عمومی (خواندن بدون تأیید هویت) و نوشتن فقط برای مدیران از طریق Cloud Functions با بررسی حقوق است. Download URL محصول در Firestore در کنار سایر داده‌های محصول ذخیره می‌شود که امکان نمایش تصاویر را بدون درخواست‌های اضافی به Storage فراهم می‌کند.

پیام‌رسان‌ها و چت‌ها در Firebase Storage تصاویر و پیام‌های صوتی ارسال‌شده در دیالوگ‌ها را ذخیره می‌کنند. مسیر به صورت /chats/{chatId}/messages/{messageId}.jpg ساخته می‌شود. دسترسی خواندن — فقط برای شرکت‌کنندگان چت، که از طریق Security Rules با استفاده از داده‌های Firestore بررسی می‌شود. این یکی از سناریوهای نادری است که قانون داده‌ها را از سرویس دیگر Firebase می‌خواند: allow read: if firestore.exists(/databases/(default)/documents/chats/{chatId}/members/{request.auth.uid}).