Ölçekli dosya yüklemeleri: doğrulama, depolama ve erişim

Ölçekli dosya yüklemelerini zorlaştıran ne?\n\nBirkaç test kullanıcısıyla dosya yüklemek basit görünür. Gerçek kişiler gerçek dosyalar göndermeye başlayınca iş zorlaşır: büyük fotoğraflar, taranmış PDF'ler ve uzantısı yanlış olan gizemli belgeler. O noktada ölçekli dosya yüklemeleri bir formdaki butondan çıkıp güvenlik ve operasyon sorunu haline gelir.\n\nİlk çatlaklar genellikle üç yerde görünür: güvenlik, maliyet ve gizlilik. Saldırganlar kötü amaçlı yazılım yüklemeye çalışır, kullanıcılar uygulamanızın açamadığı dosyalar yükler ve ekipler hassas belgeleri herkese açık bir URL üzerinden yanlışlıkla açığa çıkarır. Depolama faturaları büyür ve aynı dosya tekrar tekrar indirildikçe bant genişliği artar.\n\nGörüntüler ve PDF'ler farklı sorunlar yaratır. Görüntüler çok büyük olabilir, birçok formatta gelir ve genellikle konum gibi gizli meta veriler içerir. Uygulamayı hızlı tutmak için küçük resimler ve yeniden boyutlandırma gerekir. PDF'ler ise güvenli önizleme açısından zordur, gömülü içerik barındırabilir ve genellikle geniş erişim verilmemesi gereken (faturalar, kimlikler, sözleşmeler) hassas kayıtlar içerir.\n\nÖlçeklendiğinde genellikle aynı anda daha fazla kullanıcı yükleme yapar, dosyalar daha büyük ve toplam depolama artar, kararsız ağlardan kaynaklanan daha fazla indirme ve yeniden deneme olur ve daha fazla kural ortaya çıkar: farklı ekipler, roller ve saklama ihtiyaçları.\n\nHedef, "çalışan yüklemeler" değildir. Hedef, aylar sonra bile yönetmesi kolay kalacak güvenli yüklemelerdir: net kurallar, öngörülebilir depolama yolları, denetlemeye uygun meta veriler ve işinizin dosyaları gerçekte nasıl paylaştığına uyan erişim kontrolleri.\n\n## Dosya türlerinizi ve kimlerin erişmesi gerektiğini haritalayın\n\nDepolama veya güvenliği ayarlamadan önce, insanların ne yükleyeceği ve kimin görebileceği konusunda net olun. Ölçekte ortaya çıkan çoğu yükleme sorunu aslında depolama sorunu değildir. Beklentilerin erişim, saklama ve risk açısından uyuşmamasıdır.\n\nGerçek dosya kategorilerini listeleyerek başlayın, sadece "dokümanlar" ve "görseller" demeyin. Bir avatar bir sözleşme PDF'sinden çok farklı davranır ve bir destek ekran görüntüsü aylık bir rapordan farklıdır.\n\nYüklemeleri haritalamanın pratik bir yolu, her kategoriyi bir erişim desenine bağlamaktır:\n\n- Avatarlar ve halka açık profil görselleri genellikle birçok kişi tarafından okunabilir ve yalnızca sahibi tarafından düzenlenebilir.\n- Makbuzlar ve faturalar varsayılan olarak gizlidir, yalnızca finans rollerine veya hesap sahibine paylaşılır.\n\n- Sözleşmeler ve uyum dosyaları sıkı şekilde kısıtlanır ve genellikle denetim izleri ve daha katı saklama kuralları gerektirir.\n\n- Raporlar ve dışa aktarımlar bir ekip içinde paylaşılabilir ancak doğru çalışma alanı veya müşteriye göre sınırlandırılmalıdır.\n\n- Ticket ekleri genellikle ticket katılımcılarına özeldir ve bazen süreyle sınırlı olur.\n\nSonra hızlı bir risk özeti alın. Yüklemeler kötü amaçlı yazılım gizleyebilir, hassas verileri sızdırabilir (kimlikler, banka bilgileri, sağlık bilgileri) veya bir URL tahmin edilerek erişim veren kırık izinleri ortaya çıkarabilir. Bu yüzden ölçekli dosya yüklemeleri byte'lardan çok dosya erişim kontrolüyle ilgilidir.\n\nPerformans da önemlidir. Büyük PDF'ler, yüksek çözünürlüklü görseller ve dalgalı mobil ağlar kısmi yüklemelere ve tekrar denemelere neden olur. Hangi yüklemelerin güvenilir şekilde başarılı olması gerektiğine (faturalar, kimlikler) ve hangilerinin isteğe bağlı olduğuna (profil banner'ı) baştan karar verin.\n\nHer dosya türü için, daha sonra yeniden yazmak zorunda kalmamak için erken cevaplayın:\n\n- Kim yükleyebilir, görüntüleyebilir, değiştirebilir ve silebilir?\n- Özel mi, bir grup içinde mi paylaşılmış yoksa halka açık mı?\n- Erişim süresi dolmalı mı veya anında iptal edilebilir mi?\n- Yükleme kesintiye uğrarsa ve tekrar denense ne olur?\n- Ne kadar süre saklanır ve kim dışa aktarabilir?\n\nAppMaster gibi bir araçla geliştiriyorsanız, bu cevapları önce ürün kuralları olarak düşünün, sonra veri modelinize ve uç noktalarınıza uygulayın ki izinler web ve mobil arasında tutarlı kalsın.\n\n## Sorunları erken önleyen dosya yükleme doğrulama kuralları\n\nÖlçekli yüklemelerin güvenli ve öngörülebilir kalmasını istiyorsanız, doğrulama ilk savunma hattınızdır. İyi kurallar kötü dosyaların depolamaya ulaşmasını engeller ve kullanıcılara net geri bildirim vererek destek taleplerini azaltır.\n\nEngelleme listesi (blocklist) yerine izin listesi (allowlist) ile başlayın. Dosya adı uzantısını kontrol edin ve ayrıca yüklenen içerikten gelen MIME tipini doğrulayın. Sadece uzantıya güvenmek kolayca atlatılabilir. Sadece MIME'ye güvenmekse cihazlar arasında tutarsız olabilir.\n\nBoyut limitleri dosya türüne ve ürün kurallarınıza uygun olmalıdır. Görüntüler 5–10 MB arası iyi olabilirken, PDF'ler daha yüksek sınır gerektirebilir. Videolar tamamen farklı bir konudur ve genellikle ayrı bir işlem hattı gerekir. Ücretli planlarınız varsa, limitleri plana bağlayın ki kullanıcılara "Planınız 10 MB'a kadar PDF'lere izin veriyor" diyebilin, belirsiz bir hata mesajı yerine.\n\nBazı dosyalar daha derin kontroller gerektirir. Görüntüler için genişlik ve yükseklik (bazen en-boy oranı) doğrulanmalı ki sayfaları yavaşlatan devasa yüklemeler engellensin. PDF'lerde sayfa sayısı, kullanım durumunuz küçük bir aralık bekliyorsa önemli olabilir.\n\nYükleme sırasında dosya adlarını yeniden adlandırın. Kullanıcı dosya adları genellikle boşluk, emoji veya tekrar eden isimler içerir. Güvenli bir uzantıyla üretilmiş bir ID kullanın ve görüntüleme için orijinal adı metadata'da saklayın.\n\nBirçok uygulama için işe yarayan temel bir doğrulama seti şöyle görünür:\n\n- İzin verilen türler (uzantı + MIME), diğerlerini reddedin.\n- Tür başına maksimum boyut belirleyin (isteğe bağlı olarak plana göre).\n- Görüntü boyutlarını doğrulayın ve aşırı boyutları reddedin.\n- Kullanım durumunuz gerektiriyorsa PDF sayfa sayısını doğrulayın.\n- Güvenli, benzersiz bir dosya adına yeniden adlandırın ve orijinali metadata'da tutun.\n\nDoğrulama başarısız olduğunda, kullanıcının harekete geçebileceği tek ve net bir mesaj gösterin, örneğin: “PDF'ler 20 MB ve 50 sayfadan küçük olmalıdır.” Aynı zamanda yöneticiler için teknik detayları (algılanan MIME, boyut, kullanıcı ID'si ve neden) kaydedin. AppMaster'da bu kontroller Business Process içinde yer alabilir, böylece her yükleme yolu aynı kuralları izler.\n\n## Yüklemeler ve dosya meta verileri için veri modeli\n\nİyi bir veri modeli yüklemeleri sıkıcı hale getirir. Amaç, bir dosyanın kimde olduğunu, ne amaçla yüklendiğini ve kullanım için güvenli olup olmadığını takip etmektir; bunu bir depolama sağlayıcısına bağlamadan yapmak gerekir.\n\nGüvenilir bir desen iki adımlı akıştır. İlk olarak veritabanında bir yükleme kaydı oluşturun ve bir upload ID döndürün. İkinci olarak, baytları o ID'yi kullanarak depolamaya yükleyin. Bu, bir eşleşen satırı olmayan gizemli dosyaların kovada (bucket) kalmasını önler ve herhangi bir byte hareket etmeden önce izinleri uygulamanıza olanak tanır.\n\nBasit bir uploads tablosu (veya koleksiyonu) genellikle yeterlidir. AppMaster'da bu, Data Designer'da PostgreSQL modeliyle temiz bir şekilde eşleşir ve web ile mobil uygulamalarda kullanılabilir.\n\nDestek ve denetimler için daha sonra gerçekten ihtiyaç duyacağınız bilgileri saklayın:\n\n- Sahip referansı (user_id) ve kapsam (org_id veya team_id)\n- Amaç (avatar, invoice_pdf, ticket_attachment)\n- Orijinal dosya adı, algılanan MIME tipi ve size_bytes\n- Depolama göstericisi (bucket/container, object_key) ve isteğe bağlı checksum\n- Zaman damgaları (created_at, uploaded_at) ve yükleyenin IP/cihazı (isteğe bağlı)\n\nDurum modelini küçük tutun ki okunması kolay kalsın. Çoğu ürün için dört durum yeterlidir:\n\n- pending: kayıt var, yükleme tamamlanmadı\n- uploaded: baytlar depolandı\n- verified: kontroller geçti ve kullanıma hazır\n- blocked: kontroller başarısız veya politika gereği engellendi\n\nİlk günden temizlik planlayın. Kullanıcılar sekmeyi kapattığında veya bağlantıyı kaybettiğinde terk edilmiş pending yüklemeler olur. Günlük bir iş, süresi dolmuş pending satırlar için depolama nesnelerini silebilir, raporlama için satırları iptal edilmiş olarak işaretleyebilir, blocked öğeleri saklama penceresinden sonra kaldırabilir ve verified dosyaları iş kurallarınız izin verene kadar saklayabilir.\n\nBu model izlenebilirlik ve kontrol sağlar, fazla karmaşıklık eklemeden.\n\n## Zaman içinde düzenli kalan depolama organizasyonu\n\nDosya yüklemeleri ölçeklendiğinde, en büyük risk depolama maliyeti değil, düzensizliktir. Ekibiniz bir dosyanın ne olduğunu, kime ait olduğunu ve güncel olup olmadığını söyleyemezse, hatalar yaparsınız ve veri sızdırırsınız.\n\nBir tahmin edilebilir klasör stratejisi seçin ve ona bağlı kalın. Birçok ekip önce tenant (şirket) sonra amaç sonra tarih ile organize eder. Diğerleri tenant, kullanıcı, amaç şeklinde yapar. Tam seçimden ziyade tutarlılık önemlidir. Tarihler dizinlerin kontrolden çıkmasını önler ve temizleme işlerinizI basitleştirir.\n\nYollara kişisel veriler koymaktan kaçının. E-posta adresleri, tam isimler, fatura numaraları veya telefon numaraları gibi bilgileri gömülmüş anahtarlar kullanmayın. Bunun yerine rastgele ID'ler kullanın. İnsan anlamlı arama yapmanız gerekirse, bunu nesne anahtarında değil veritabanı meta verisinde saklayın.\n\nOrijinallerle türevleri ayrı tutun ki kurallar net kalsın. Orijinal yüklemeyi bir kez depolayın ve küçük resimler veya önizlemeleri farklı bir prefix altında saklayın. Bu, farklı saklama ve izin politikalarını uygulamayı kolaylaştırır (örneğin bir önizleme orijinalden daha geniş alanlarda gösterilebilir).\n\nBasit, dayanıklı bir adlandırma yaklaşımı:\n\n- Tenant ID (veya workspace ID) ile bölümlendirin\n- Amaç öneki ekleyin (avatars, invoices, attachments)\n- Zaman kovası ekleyin (YYYY/MM)\n- Dosya adı olarak opak bir dosya ID'si kullanın\n- Türevleri ayrı bir önek altında saklayın (previews, thumbnails)\n\nSürümleri nasıl yöneteceğinize karar verin. Kullanıcılar dosya değiştirebiliyorsa, ya aynı nesne anahtarını üzerine yazın (basit, geçmiş yok) ya da yeni bir versiyon oluşturup eskisini pasif olarak işaretleyin (uyum için daha elverişli). Birçok ekip uyum belgeleri için geçmiş tutar ve profil resimleri için üzerine yazar.\n\nAdlandırma kurallarınızı yazılı hale getirin. AppMaster'da bunu paylaşılan bir konvansiyon olarak ele alın: proje belgelerinizde tutun ki backend mantığı, UI oluşturucular ve gelecekteki entegrasyonlar aynı yolları üretsin.\n\n## İzinler ve erişim kontrolü desenleri\n\nÖlçekli dosya yüklemelerinde, izinler küçük kestirmelerin büyük olaylara dönüştüğü yerdir. Varsayılan olarak reddetmeyle başlayın: her yüklenen dosya, açıkça izin verilene kadar özel olsun.\n\nİki soruyu ayırmak yardımcı olur: kim kayıtı görebilir ve kim byte'ları alabilir. Bunlar aynı şey değildir. Pek çok uygulama, birinin meta veriyi (dosya adı, boyut, yükleme tarihi) görmesine izin verirken indirme yetkisini kısıtlamalıdır.\n\n### Yaygın erişim desenleri\n\nHer dosya türü için bir birincil desen seçin, sonra istisnaları dikkatli ekleyin:\n\n- Sadece sahip: yalnızca yükleyen (ve servis hesapları) indirebilir.\n- Takım tabanlı: çalışma alanı/proje üyeleri indirebilir.\n- Role dayalı: Finans veya İK gibi roller takımlar arasında indirebilir.\n- Bağlantıyla paylaşım: özel bir token indirme izni verir, genellikle süre sınırı ve kapsam içerir.\n\nKenar durumlar için net kurallar belirleyin, tek seferlik düzeltmeler değil. Yöneticilerin nasıl çalıştığını (küresel erişim mi yoksa yalnızca belirli kategoriler mi), desteğin geçici erişimi nasıl alacağını (zaman kutulu ve kaydedilen) ve bir kullanıcı silindiğinde ne olacağını (uyum için dosyaları sakla, sahipliği yeniden ata veya sil) karar verin.\n\n### Meta veri ve indirmeleri ayrı ele alın\n\nBasit bir desen iki kontroldür: (1) kullanıcı upload kaydını okuyabilir mi, (2) kullanıcı bir indirme isteği yapabilir mi. İkinci kontrol "izin verilene kadar özel" kuralını uygular, birisi rastgele bir ID tahmin etse bile.\n\nHassas belgeler için erişimi kaydedin. En azından kim indirdi (kullanıcı ID ve rol), ne indirildi (dosya ID ve tür), ne zaman oldu (zaman damgası), neden izin verildi (politika sonucu, paylaşım token'ı, yönetici geçersiz kılma) ve nereden geldi (IP veya cihaz, uygunsa) bilgilerini tutun.\n\nAppMaster'da bu kurallar genellikle Business Process Editor içinde yer alır: upload meta verilerini listeleyen bir akış ve indirme yanıtı oluşturan daha sıkı bir akış.\n\n## Süresi dolan indirme linkleri: sürtünme olmadan daha güvenli indirmeler\n\nSüresi dolan indirme linkleri “URL'ye sahip olan herkes sonsuza dek indirebilir” ile “kullanıcı her seferinde giriş yapmak zorunda” arasındaki iyi bir orta yoldur. E-posta ile belge paylaşmak, bir yüklenene geçici erişim vermek veya tek seferlik indirmeler için uygundur. Ölçeklendiğinde, depolamanızı tamamen açmadan erişim vermenizi sağladığı için destek sorunlarını da azaltır.\n\nİki yaygın desen:\n\n- İmzalı URL'ler otomatik olarak süresi dolar. Basit ve hızlıdır, ancak link zaten dışarı çıktıysa iptali zordur.\n- Token tabanlı indirme uç noktası daha fazla kontrol sağlar. Link kısa bir token içerir, uygulamanız her istekte izinleri kontrol eder ve sonra dosyayı sunar veya yönlendirir.\n\nPratik bir kurulum:\n\n- Paylaşılan linkler için kısa süreler kullanın (10–60 dakika) ve istenirse yenileyin.\n- Daha uzun süreleri yalnızca güvenilir, oturum açmış kullanıcılar için tutun (örneğin “Tekrar indir” yeni bir link oluşturur).\n- Linkleri sıkı şekilde kapsamlayın: bir dosya, bir kullanıcı (veya alıcı), bir eylem (görüntüleme vs indirme).\n- Link oluşturma ve kullanımını kaydedin ki sızıntıları tahmin etmek zorunda kalmayın.\n\nKapsam önemlidir çünkü görüntüleme genellikle satır içi gösterim anlamına gelir, indirme ise kopya kaydetmeyi içerir. Her ikisine de ihtiyaç varsa, ayrı kurallara sahip ayrı linkler oluşturun.\n\nİptal planı yapın. Bir kullanıcı erişimini kaybederse (iade, rol değişikliği, sözleşme sona ermesi) imzalı URL'ler tek başına yeterli olmayabilir. Token uç noktası ile token'ları hemen geçersiz kılabilirsiniz. İmzalı URL'lerde ise kısa süreler tutun ve yalnızca gerektiğinde imzalama anahtarlarını döndürün (anahtar döndürme her şeyi iptal eder, dikkatle kullanın).\n\nÖrnek: Bir müşteri portalında muhasebeciye e-posta ile gönderilen fatura linki 30 dakika sonra süresi dolar, yalnızca görüntüleme izni verir ve o fatura ID'si ile müşteri hesabına bağlıdır. Müşteri hesaptan kaldırılırsa token süresi dolmamış olsa bile token reddedilir.\n\n## Adım adım: ölçeklenebilir bir yükleme akışı\n\nGüvenilir bir yükleme akışı üç konuyu ayırır: neye izin veriyorsunuz, baytlar nereye gidiyor ve kim daha sonra bunları alabilir. Bunlar karıştığında küçük kenar durumlar üretim sorunlarına dönüşür.\n\nGörüntüler, PDF'ler ve çoğu kullanıcı kaynaklı dosya için pratik bir akış:\n\n1. Amaç bazlı kuralları tanımlayın. Her amaç (avatar, fatura, kimlik belgesi) için izin verilen türleri, maksimum boyutu ve max sayfa gibi ekstra kontrolleri belirleyin.\n2. Backend'de bir yükleme isteği oluşturun. İstemci yükleme izni ister. Backend bir yükleme hedefi döndürür (örneğin bir nesne depolama anahtarı ve kısa ömürlü bir token) ve pending durumuyla yeni bir upload satırı oluşturur.\n3. Baytları depolamaya yükleyin, sonra onaylayın. İstemci nesne depolamaya yükler, sonra backend'e tamamlandığını bildirir. Backend beklenen anahtarı ve temel özellikleri kontrol eder, sonra satırı uploaded olarak işaretler.\n4. Asenkron doğrulama çalıştırın. Arka planda gerçek dosya tipini doğrulayın (mümkünse magic bytes dahil), boyutu denetleyin, güvenli meta verileri çıkarın (boyutlar, sayfa sayısı) ve isteğe bağlı olarak kötü amaçlı yazılım taraması yapın. Başarısız olursa, yüklemeyi blocked olarak işaretleyin ve indirmeleri engelleyin.\n5. İndirmeleri politika aracılığıyla sunun. İndirmede, kullanıcının dosyanın sahibi olan varlığa (kullanıcı, org, ticket, sipariş) erişimi olduğunu doğrulayın. Sonra indirmeyi proxy'leyin veya depolamayı özel tutmak için süresi dolan indirme linkleri döndürün.\n\nTemizlik ekleyin. Kısa bir süre sonra terk edilmiş pending yüklemeleri silin ve referanssız dosyaları kaldırın (örneğin kullanıcı bir görsel yükledi ama formu hiç kaydetmedi).\n\nAppMaster ile inşa ediyorsanız, upload'ları kendi varlığı olarak modelleyin, bir status alanı ve sahip referansları ekleyin, sonra her indirme Business Process'inde aynı izin kontrollerini uygulayın.\n\n## Örnek: müşteri portalında faturalar\n\nKullanıcıların PDF olarak fatura yüklediği bir müşteri portalı, binlerce şirket, birçok rol ve aynı faturanın üç kez değiştirilmesi olunca basit görünmeyi bırakır.\n\nDepolama organizasyonu için, ham dosyayı insanların arama yaptığı şekilde öngörülebilir bir yola koyun. Örneğin: invoices/<company_id>/<yyyy-mm>/<upload_id>.pdf. Şirket ve ay temizleme ve raporlama yapmayı kolaylaştırır, upload_id ise aynı ada sahip iki dosyanın çakışmasını önler.\n\nVeritabanında dosyanın ne olduğunu ve kimlerin erişebileceğini açıklayan meta veriyi saklayın:\n\n- company_id ve billing_month\n- uploaded_by_user_id ve uploaded_at\n- original_filename ve content_type\n- size_bytes ve checksum (isteğe bağlı)\n- status (active, replaced, quarantined)\n\nPaylaşım için: bir faturalama yöneticisi bir faturayı harici bir muhasebeciye 24 saatliğine göndermek istiyor. Global izinleri değiştirmek yerine, o belirli fatura için katı bir süre ve tek amaçlı (sadece indirme) bir süresi dolan indirme linki oluşturun. Muhasebeci tıkladığında uygulamanız token'ı kontrol eder, süresinin dolmadığını doğrular ve sonra dosyayı sunar.\n\nKullanıcı yanlış PDF yüklediyse veya bir dosyayı değiştirdiyse, eski nesneyi üzerine yazmayın. Önceki kaydı replaced olarak işaretleyin, denetim için saklayın ve fatura girdisini yeni upload_id'ye yönlendirin. Saklama kurallarını uygulamanız gerekirse, değiştirilmiş dosyaları daha sonra zamanlanmış bir iş ile silebilirsiniz.\n\nDestek bir "indiremiyorum" bileti aldığında, meta veri hızlıca teşhis yapmayı sağlar: linki süresi doldu mu, fatura replaced olarak mı işaretlendi, kullanıcı doğru şirkete mi ait yoksa dosya quarantined mı? AppMaster'da bu kontroller Business Process içinde yer alır, böylece her indirme aynı kuralları izler.\n\n## Yaygın hatalar ve nasıl kaçınılır\n\nEkipler dosya yüklemeleriyle ilk kez uğraşırken hatalar nadiren gizemlidir. Demo'da iyi gözüken birkaç kestirme, daha sonra zarar verir.\n\n- Sadece dosya uzantısına veya sadece MIME tipine güvenmek. Saldırganlar dosyaların adını değiştirebilir ve tarayıcılar yanıltıcı bilgi verebilir. İkisini de kontrol edin ve sunucu tarafında magic bytes doğrulaması yapın.\n\n- Genel erişime açık depolama kullanmak ve izinlerin yeterli olmasını ummak. Genel bir bucket/container her kaçırılmış kuralı veri sızıntısına çevirir. Depolamayı varsayılan olarak özel tutun ve erişimi uygulamanızın üzerinden gate edin.\n\n- Kullanıcı tarafından sağlanan adları depolama yollarında veya URL'lerde kullanmak. invoice_john_smith.pdf gibi adlar kişisel bilgileri sızdırır ve tahmin etmeyi kolaylaştırır. Nesne anahtarları için rastgele ID'ler kullanın, gösterim adı olarak metadata'da saklayın.\n\n- Tenant dosyalarını güçlü kontroller olmadan aynı yolda karıştırmak. /uploads/2026/01/ gibi bir yol bir izin modeli değildir. Bir indirme döndürmeden önce her zaman tenant ve kullanıcı haklarını doğrulayın.\n\n- Başarısız veya terk edilmiş yüklemeler için temizlemeyi atlamak. Çok parçalı yüklemeler ve tekrar denemeler gereksiz çöp bırakır. Hiç tamamlanmamış pending yüklemeleri kaldıracak bir arka plan işi ekleyin.\n\nEkiplerin unuttuğu bir başka hata da tekrarlar ve kopyalar için plan olmamasıdır. Mobil ağlar kopar. Kullanıcılar iki kere dokunur. Sistemin "aynı dosyayı tekrar yüklemek" normal bir davranış olduğunu kabul etmesi gerekir.\n\nPratik yaklaşım, önce bir upload ID üretmek, sonra chunk'ları veya tek dosyayı kabul etmek ve doğrulama geçtikten sonra kaydı verified yapmak. Aynı yükleme tekrar edilirse, ikinci bir kopya yerine mevcut kaydı döndürün.\n\nAppMaster içinde inşa ediyorsanız, çekirdek kuralları tek bir yerde (backend mantığı) tutun ki web ve mobil aynı şekilde davransın, UI değişse bile.\n\n## Yayına almadan önce hızlı kontrol listesi\n\nGerçek kullanıcılara açmadan önce temel noktaları hızlıca gözden geçirin. Ölçekli dosya yüklemelerindeki çoğu sorun, ancak çok sayıda kullanıcı, çok sayıda dosya ve birçok kenar durum olduğunda ortaya çıkan küçük boşluklardan kaynaklanır.\n\n- İzin verilen dosya türleri ve kullanım durumu başına boyut limitleri belirleyin (avatar vs fatura). Hem uzantıyı hem de gerçek içerik tipini doğrulayın.\n- Yükleme meta verilerini veritabanında kaydedin: kime ait olduğu (kullanıcı, ekip, hesap), ne için olduğu ve pending, verified veya blocked gibi açık bir durum.\n- Depolamayı varsayılan olarak özel tutun ve her indirmede izin kontrollerini zorunlu kılın (gizli URL'lere güvenmeyin).\n- Paylaşım gerektiğinde süresi dolan indirme linkleri kullanın ve süreleri kısa tutun (dakikalar veya saatler, günler değil).\n- Yollarda kişisel veriler kullanmaktan kaçının. Rastgele ID'ler kullanın ve UI'da dostça bir gösterim adı gösterin.\n\nTerk edilmiş yüklemeler için bir yanıtınız olsun. Kullanıcıların bir yüklemeyi başlatıp hiç bitirmemesi veya dosyaları sık değiştirmesi normaldir.\n\nBasit bir temizleme planı:\n\n- verified olmayan, hiçbir zaman tamamlanmamış orphaned dosyaları belirli bir süreden sonra silin.\n- Değiştirilmiş dosyalar için bir saklama penceresi tutun, sonra kaldırın.\n- Destek incelemesi için önemli olayları (yükleme, doğrulama, indirme, silme) kaydedin.\n\nAppMaster ile inşa ediyorsanız, metadata'yı Data Designer aracılığıyla PostgreSQL'de saklayın, kontrolleri Business Process Editor içinde uygulayın ve dosya sunmadan önce kısa ömürlü indirme token'ları üretin.\n\n## Sonraki adımlar: güvenle yayınlayın, sonra küçük adımlarla geliştirin\n\nGüvenli bir sürüme en hızlı yol, bir yükleme yaklaşımı seçmek ve ona sadık kalmaktır. Dosyaların önce backend'inizden mi geçeceğine yoksa kısa süreli token ile doğrudan nesne depolamaya mı yükleneceğine karar verin. Sonra tam adımları ve her adımın (istemci, backend, depolama) sahibini yazın. Tutarlılık, ölçekli dosya yüklemelerinde ustalığa tercih edilir.\n\nBaşlangıçta katı varsayılanlar koyun. Gerçekten ihtiyaç duyduğunuz dosya türlerini sınırlayın, boyut limitlerini muhafazakar tutun ve halka açık olmaması gereken her şey için kimlik doğrulama zorunlu kılın. Kullanıcılar daha büyük dosyalar veya daha fazla format isterse, bir seferde bir kuralı gevşetin ve etkisini ölçün.\n\nErken temel izleme ekleyin ki sorunlar çabuk ortaya çıksın:\n\n- Yükleme hatası oranı (cihaz, tarayıcı ve dosya türüne göre)\n- Ortalama ve p95 yükleme boyutu\n- Yükleme süresi (özellikle mobil ağlarda)\n- Günlük veya haftalık depolama artışı\n- İndirme hataları (süresi dolmuş veya yasaklanmış linkler dahil)\n\nBu yükleme sistemi daha büyük bir uygulamanın parçasıysa, veri modeli ve izinleri iş mantığınıza yakın tutun. AppMaster kullanan ekipler genellikle upload kayıtlarını PostgreSQL'de tutar, doğrulamayı ve dosya erişim kontrolünü Business Process içinde uygular ve aynı mantığı backend, web ve native mobil uygulamalarda tekrar kullanır.\n\nİlerlemede faydalı bir sonraki adım, yaygın formatlar için önizlemeler eklemek, hassas belgeler için denetim günlükleri tutmak veya basit saklama kuralları eklemek (örneğin geçici yüklemeleri 30 gün sonra otomatik silme). Küçük, istikrarlı iyileştirmeler kullanım büyüdükçe sistemi güvenilir tutar.