Who is this for?
Mobile teams accepting photos, documents or user media.
Before you start
An object storage provider, private bucket and ownership model.

1. Separate authorization and transfer

The API decides ownership and accepted size/type. Provider-specific signed URLs or POST policies can transfer the body directly to storage. Match the flow to your provider’s supported conditions. This is an architectural example; Uygulama Cloud does not currently provision customer object storage.

2. Scope temporary permission

Generate the object key on the server. Limit permission to a specific object, operation and duration. Anyone holding the signed URL may use its granted access, so keep it out of logs and public messages. Expiration does not automatically mean single use.

Client → API: upload request
API → Client: upload_id + temporary permission
Client → Storage: body
Client → API: complete
API verifies object → ready / rejected

3. Verify content and size

Do not trust extensions or client MIME types. Check stored size and apply content checks appropriate to the product. Keep uncertain files quarantined. Run transformations in a bounded worker instead of allowing large images to monopolize the API.

3. Verify content and size
CheckPurpose
OwnershipPrevent cross-account access
Size / typeEnforce limits
CompletionAvoid exposing missing objects
Quota / retentionBound storage growth

4. Track state explicitly

Use pending, uploaded, processing, ready and rejected states. Repeated completion for the same upload must not create duplicate metadata. SQL and storage do not share a normal database transaction, so provide recovery tasks for partial success.

5. Clean up interrupted work

Expire stale pending records and orphan objects carefully. Configure unfinished multipart retention where applicable. Define deletion and backup retention for account removal. Confirm permission before publishing private media through a public CDN URL.

6. Test real interruptions

Disconnect after permission issuance, lose the completion response, submit another user’s identifier and attempt invalid content or oversized files. A refreshed permission should preserve the same logical upload.

  • No storage secrets in the app.
  • Bound account usage at authorization and completion.
  • Do not show pending media as ready.
  • Monitor and recover incomplete work.

Action summary

  • Issue scoped upload permission.
  • Verify before publication.
  • Recover storage/metadata partial failures.

Common questions

Is a signed URL single-use?

Do not assume so. Verify provider semantics and track application completion separately.

Is transfer success sufficient?

No. Verify ownership, content, processing and metadata consistency.

Sources and scope

Technical references are listed below. Examples illustrate implementation in your own environment; they are not customer benchmarks or claims of live Uygulama Cloud services. Check the current provider documentation before applying settings.

Sources checked:

Read next

Browse all articles