Richiesta di funzionalità: upload sicuri per backend S3 senza ACL per oggetto

Problema

Nei backend compatibili con S3 che non supportano ACL per oggetto, secure_uploads non può coesistere con contenuti serviti pubblicamente.

Sembra che avatar e asset del tema/sito vengano serviti tramite URL S3 diretti e non autenticati, il che richiede la lettura pubblica sull’oggetto. Ma lo stesso bucket contiene upload di post sicuri che dovrebbero rimanere privati nella mia configurazione desiderata — e entrambi (file pubblici e privati) condividono gli stessi prefissi di percorso (original/..., optimized/...). Senza ACL per oggetto, non c’è modo di rendere pubblici i file pubblici e privati gli altri file.

La mia situazione attuale: avatar e asset sono danneggiati (il bucket è privato → 403 per quei file), mentre gli upload di post sicuri funzionano correttamente tramite il proxy /secure-uploads/.

Il conflitto principale

Gli upload sicuri richiedono un percorso di lettura autenticato; avatar/asset richiedono un percorso non autenticato. Entrambi si trovano dietro lo stesso confine a livello di bucket, che non può distinguerli senza ACL per oggetto.

Soluzioni richieste

  1. Servire avatar/asset tramite URL presigned quando il bucket è privato e le ACL sono disabilitate — stesso meccanismo degli upload sicuri. Dal mio punto di vista, questo potrebbe funzionare anche solo per gli utenti connessi per scenari con un’istanza Discourse non pubblica.
  2. Supportare bucket o prefissi separati per asset pubblici rispetto agli upload sicuri, in modo che il confine di accesso si allinei con il confine pubblico/privato e si possano creare ACL appropriate.

Qualcuno di questi approcci è fattibile, o c’è già un percorso supportato che ho perso?

2 Mi Piace

Ho appena riscontrato esattamente questo problema nel tentativo di implementare Discourse su Azure, che non offre alcun servizio compatibile con S3. Di conseguenza, stiamo cercando di eseguire un server di file locale, ma nessuno di essi offre ACL per singolo oggetto.