Firebase Storage: шта је то, отпремање датотека и складиштење у облаку

Шта је Firebase Storage и како је уређен

Firebase Storage — то је облачно објектно складиште изграђено на бази Google Cloud Storage-а, које пружа SDK за Android, iOS и веб платформе. Свака датотека се чува као објекат у Google Cloud бакету и адресира се путем који подсећа на систем датотека: gs://bucket-name/path/to/file.jpg. Величина једне датотеке може достићи до 5 ТБ, што омогућава чување било којих медијских података без претходне компресије.

Архитектура 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) укључује 5 ГБ складишта, 20.000 операција писања и 50.000 операција читања дневно. Платна тарифа (Blaze) наплаћује се по стварном коришћењу: $0,026 по ГБ складиштених података, $0,05 на 10.000 операција писања и $0,004 на 10.000 операција читања. Додатно се наплаћује одлазни саобраћај.

За већину мобилних апликација са неколико хиљада корисника, бесплатни лимит је довољан у фази прототипирања и тестирања. При скалирању на стотине хиљада корисника, трошкови за Storage ретко прелазе $50–$100 месечно уз оптимизован приступ отпремању и кеширању на страни клијента.

Како отпремати датотеке у 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-ова паралелно без ограничења. На мобилним уређајима паралелно отпремање више од 3–5 датотека доводи до преоптерећења мрежног стека и тајм-аута. Оптимална стратегија је коришћење конкурентног лимита 3 или секвенцијално отпремање са приказом заједничке траке напретка.

За серверску обраду након отпремања (генерисање сличице, компресија, модерација садржаја) користите тригер 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 — зато је токен једина заштита download линка.

Кеширање и рад са ETag-ом

HTTP ETag — то је идентификатор верзије датотеке који се мења при свакој промени садржаја. Firebase Storage аутоматски враћа ETag у одговору на GET захтев. Клијентска апликација може сачувати ETag у локалном кешу и при поновном захтеву послати заглавље If-None-Match: {etag}. Ако се датотека није променила, сервер ће вратити статус 304 Not Modified без преноса података.

За реализацију интелигентног кеширања у мобилној апликацији користите комбинацију локалног система датотека и базе података (на пример, Room за чување парова путања-ETag). При преузимању датотеке проверите ETag из базе: ако се поклапа са серверским, користите локалну копију. Овакав приступ смањује саобраћај за 60–80% за статичке медијске датотеке и убрзава учитавање екрана са галеријама.

Безбедносна правила за 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}/, али може да чита било коју датотеку у том директоријуму (галерија је јавна). Величина датотеке је ограничена на 5 МБ, а тип — само слике. Оваква комбинација правила покрива 80% сценарија коришћења Firebase Storage-а у друштвеним и UGC апликацијама.

Савет о безбедности: никада не користите правило allow read, write: if true за цео бакет. Ово отвара приступ за писање свакоме ко зна ваш projectId. У 2025. години учестали су напади на незаштићене бакете Firebase-а, када су злонамерни корисници користили отворени приступ за чување илегалног садржаја. Увек почињете са минимално потребним правима и проширујте их само када је то изричито потребно.

Валидација садржаја преко Cloud Functions-а

Cloud Functions тригер functions.storage.object().onFinalize() омогућава проверу садржаја након отпремања. Ако датотека не прође валидацију (на пример, садржи вирус или крши правила платформе), функција може да је обрише и обавести корисника. Ово је једини начин провере стварног садржаја, јер Security Rules виде само метаподаке (величину и MIME тип), а не бинарне податке.

Пример валидације: функција на Node.js преузима отпремљену датотеку у привремени директоријум, пропушта је кроз антивирусни детектор (на пример, ClamAV) и ако се претња открије — брише датотеку и уписује догађај у Firebase Crashlytics. Време извршења функције је ограничено на 540 секунди, што је довољно за проверу датотека величине до 50 МБ.

Примери кода за 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() учитава целу датотеку у меморију. За датотеке веће од 10 МБ користите getFile() — он чува садржај директно у локалну датотеку без задржавања у 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 blog-у (2025), овај шаблон се користи у 70% production пројеката на Firebase-у.

E-commerce апликације користе 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}).