URL S3 CDN non utilizzata sugli upload non di immagini

Contribuisci Bug
1

Forse correlato a S3 CDN URL ignorato durante il caricamento nei post.

Inizialmente ho pensato di aver saltato qualche configurazione, ma il problema è riproducibile qui su meta:
https://meta.discourse.org/uploads/short-url/dw1U4hctATusBlHsUmWQXeme66j.csv (caricato qui) è un reindirizzamento 302 verso
//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/5/e/5ebb2cfb8cc907e8e8f7c6559a72d2f4a8ba2f8f.csv

Non dovrebbe invece reindirizzare a https://d11a6trkgmumsb.cloudfront.net/original/3X/5/e/5ebb2cfb8cc907e8e8f7c6559a72d2f4a8ba2f8f.csv?

5 Mi Piace
S3 Uploads - Using CDN for PDFs?
2

Hmm, potrebbe esserci un problema qui @martin, puoi indagare? Dovremmo probabilmente reindirizzare al CDN se possibile.

5 Mi Piace
4

È un po’ complicato, ho appena dato un’occhiata. Fondamentalmente, quando eseguiamo un “download forzato”, scarichiamo sempre da S3 tramite un URL firmato, come avviene quando si clicca sul link dell’allegato o sul pulsante Download di un’immagine. Questo serve per poter aggiungere le intestazioni content-disposition appropriate:

attachment; filename="#{upload.original_filename}"; filename*=UTF-8''#{upload.original_filename}

Non credo sia possibile far sì che l’URL del CDN si comporti in questo modo? L’URL del CDN per le immagini viene utilizzato solo per visualizzarle in linea, non per scaricarle. Inoltre, nel caso di immagini e allegati protetti con ACL privata, l’URL firmato deve essere utilizzato sempre.

2 Mi Piace
Link to data export on S3 does not use CDN URL
Why is my upload limit 100mb?It's set to 500mb
5

@martin per quanto riguarda i collegamenti agli allegati, non capisco come possano essere impostati per “forzare il download” sempre. Al momento, quando si carica un file non immagine, l’URL renderizzato risultante è un URL breve senza il parametro ?dl=1 che viene risolto al valore dell’attributo url dell’upload corrispondente (che non è un URL presigned e fallisce anche nel nostro caso poiché l’URL non è il cdn_url di S3 ma uno costruito che potrebbe funzionare solo per determinati provider S3).

C’è un modo per forzare sempre il download degli allegati, o il comportamento attuale è in realtà un bug?

1 Mi Piace
6

Puoi spiegare meglio, stai usando Amazon S3 o un provider diverso? Se sì, quale?

1 Mi Piace
7

Sì, sembra che io stia usando un provider S3 non supportato (OVH Object Storage)

Con un URL dell’endpoint di https://s3.de.ovh.cloud.net e un s3 cdn_url configurato su https://storage.de.ovh.cloud.net/v1/<some-unique-user-id>/<the-bucket-name>

Quando gli URL brevi vengono risolti, discourse utilizza l’URL dell’endpoint per costruire l’URL risultante (che fallisce poiché non include l’ID utente OVH corretto, la parte nel s3 cdn_url).

Forzare gli URL brevi ad avere dl=1 tuttavia costruirebbe un presigned_url funzionante che andrebbe bene per me.

Ho impostato queste variabili d’ambiente (specifiche S3) all’interno del file YAML del container:

DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: DE
DISCOURSE_S3_ENDPOINT: https://s3.de.cloud.ovh.net
DISCOURSE_S3_ACCESS_KEY_ID: ...
DISCOURSE_S3_SECRET_ACCESS_KEY: ...
DISCOURSE_S3_CDN_URL: https://storage.de.ovh.cloud.net/v1/<some-unique-user-id>/<the-bucket-name>
DISCOURSE_S3_UPLOAD_BUCKET: <the-bucket-name>
DISCOURSE_S3_INSTALL_CORS_RULE: false
1 Mi Piace
8

Forse questo esula dall’argomento, ma se il comportamento attuale è intenzionale, come o dove si potrebbe sovrascrivere il rendering degli URL brevi nel frontend? Sto pensando di semplicemente agganciarmi al processo di “cooking” dei post e quindi aggiungere il parametro di query agli URL brevi degli allegati. Sono a conoscenza di come scrivere plugin JS per Discourse, ma la maggior parte delle volte ho difficoltà a trovare il Widget giusto per “riaprire” o la funzione da sovrascrivere.

9

Ok, quindi ho trovato il punto in cui viene generato il Markdown per gli allegati e, per quanto ne capisco l’API dei plugin, non si può (facilmente) sovrascriverla (penso persino che non si dovrebbe farlo).

Quindi il mio pensiero iniziale di aggiungere un parametro ?dl=1 a quegli URL sembra essere il modo sbagliato per farlo.

Per quanto riguarda il non forzare i download per gli URL brevi risolti: se ho capito bene l’argomento contro gli ACL pubblici sui bucket S3, si dovrebbe o:

  1. servire i file da S3 tramite una CDN (non fattibile per gli allegati come ha sottolineato @martin, poiché in questo caso potremmo non essere in grado di impostare correttamente il nome del file per il download)
  2. creare un URL presignato per l’oggetto S3

Ma il comportamento attuale non fa né l’uno né l’altro e si aspetta che il bucket S3 abbia un ACL pubblico. Questo sembra essere anche il caso per i provider S3 supportati (incluso Amazon), quindi vorrei chiedere perché non rendere l’opzione force_download in Discourse.store.url_for predefinita su true (discourse/app/controllers/uploads_controller.rb at v2.8.0.beta11 · discourse/discourse · GitHub) quando si risolvono gli URL brevi per gli store S3?

1 Mi Piace
Configure an S3 compatible object storage provider for uploads
11

Ho lo stesso problema qui, quello che mi aspetto è che il file dietro uploads/short-url venga scaricato o reindirizzato all’URL del CDN S3.

2 Mi Piace
12

Stiamo riscontrando lo stesso problema con Cloudflare R2, poiché sembra non consentire l’utilizzo dell’URL S3 diretto senza un URL pre-firmato.
E R2 non supporta gli ACL per i bucket.

13

Sembra che discourse abbia recentemente aggiunto un’opzione “s3 use cdn url for all uploads” che risolve questo problema.