- Kimler için?
- Fotoğraf, belge veya kullanıcı medyası kabul eden mobil uygulama ekipleri.
- Başlamadan önce
- Seçilmiş bir object storage sağlayıcısı, özel bucket ve dosya sahipliği modeli.
1. API ile dosya transferini ayırın
Backend önce dosyanın kime ait olacağını, izin verilen boyut ve türünü belirler. Storage sağlayıcısının desteklediği kısa ömürlü imzalı URL veya POST policy ile gövde doğrudan storage’a gidebilir. Her sağlayıcının imza ve koşul desteği farklıdır; örneği kendi sağlayıcınızın dokümanıyla eşleştirin. Uygulama Cloud bugün müşteri object storage kaynağı sağlamaz; akış bir mimari örnektir.
2. İzin üretimini dar kapsamlı yapın
Nesne anahtarını sunucu oluştursun; kullanıcı başka hesapların path’ini seçemesin. İzin süresi kısa, işlem türü açık ve hedef tek nesneyle sınırlı olsun. İmzalı URL’yi gören kişi izin süresinde kullanabilir; bu yüzden log, analytics veya herkese açık mesaj içine koymayın. Bir URL’nin kısa ömürlü olması onu kendiliğinden tek kullanımlı yapmaz.
1. Mobil → API: dosya türü ve boyut isteği
2. API → Mobil: upload_id + kısa ömürlü yükleme izni
3. Mobil → Storage: dosya gövdesi
4. Mobil → API: tamamlanma isteği
5. API: nesne kontrolü → ready / rejected3. İstemci MIME bilgisini güvenilir saymayın
Dosya uzantısı ve istemcinin content-type alanı manipüle edilebilir. Boyutu storage metadata’sından kontrol edin; hassas kullanımda dosya imzası ve zararlı içerik değerlendirmesi yapın. Gerekiyorsa yüklemeyi quarantine durumunda tutun. Görsel dönüştürmeyi ayrı bir worker’da kaynak sınırıyla çalıştırın; devasa dosya API sürecini yormamalıdır.
| Kontrol | Amaç |
|---|---|
| Sahiplik | Başka hesap nesnesine erişimi engelleme |
| Boyut / tür | Kabul sınırını uygulama |
| Tamamlanma | Eksik veya olmayan dosyayı yayımlamama |
| Quota / retention | Depolamanın sınırsız büyümesini önleme |
4. Metadata’yı durum makinesiyle saklayın
pending, uploaded, processing, ready ve rejected gibi durumlar API cevabında açık olmalıdır. Ekran yalnızca ready dosyasını son kullanıcıya sunmalı. Tamamlanma isteği tekrarlanabilir; aynı upload_id ikinci dosya kaydı oluşturmamalıdır. Dosya ve SQL kaydı farklı sistemlerde olduğundan her ikisinin atomik değiştiğini varsaymayın; toparlayıcı işler tasarlayın.
5. Yarım yüklemeleri ve silmeyi planlayın
Süresi geçen pending kayıtları ve sahipsiz nesneleri kontrollü temizleyin. Multipart yüklemelerde tamamlanmamış parçaların retention kuralını sağlayıcıda ayarlayın. Hesap silindiğinde nesnelerin ne zaman temizleneceği ve yedeklerin ne kadar tutulacağı belirli olmalıdır. Özel dosyayı herkese açık CDN URL’siyle sunmadan önce erişim politikasını kontrol edin.
6. Hata senaryolarını cihazda deneyin
Upload izni alındıktan sonra bağlantıyı kesin; dosya transferinden sonra API tamamlanma cevabını kaybettirin. Süresi dolan izin için yeni izin alma akışı mevcut metadata’yı korumalıdır. Başka kullanıcıya ait upload_id, değiştirilmiş MIME ve aşırı boyut testleri yapın.
- Storage sırları mobil pakette bulunmamalı.
- İzin ve tamamlanma endpoint’i hesap kotasına tabi olmalı.
- Pending dosya ekranda ready gibi görünmemeli.
- Yarım işler için ölçüm ve temizleme görevi bulunmalı.
Uygulama özeti
- Dar kapsamlı yükleme izni üretin.
- Dosyayı doğrulamadan hazır saymayın.
- Metadata ve storage arasındaki yarım işleri toparlayın.
Sık sorulan sorular
Presigned URL tek kullanımlı mı?
Genellikle buna otomatik garanti verilmez. Sağlayıcı davranışını doğrulayın ve uygulamanın tamamlanma durumunu ayrıca takip edin.
Dosyanın yüklenmesi yeterli mi?
Hayır. Sahiplik, boyut, tür, işlenme ve metadata tutarlılığı da kontrol edilmelidir.
Kaynaklar ve kapsam
Teknik kaynaklar aşağıda. Örnekler açıklama ve kendi ortamınızda uygulama içindir; gerçek müşteri ölçümü veya çalışan Uygulama Cloud servisi iddiası içermez. Sağlayıcı ayarlarını uygulamadan önce ilgili belgenin güncel sürümünü kontrol edin.
Kaynak kontrolü: