URL S3 CDN non utilizzata sugli upload non di immagini

Bug
1

Maybe related to S3 CDN URL ignored when uploading into posts.

At first I thought I had missed some configuration, but it’s reproducible here on meta:
https://meta.discourse.org/uploads/short-url/dw1U4hctATusBlHsUmWQXeme66j.csv (uploaded here) is a 302 redirect to
//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/5/e/5ebb2cfb8cc907e8e8f7c6559a72d2f4a8ba2f8f.csv

Shouldn’t it redirect to https://d11a6trkgmumsb.cloudfront.net/original/3X/5/e/5ebb2cfb8cc907e8e8f7c6559a72d2f4a8ba2f8f.csv instead?

5 Mi Piace
2

Hmmm there may possibly be an issue here @martin can you investigate? We should probably redirect to the CDN if possible.

5 Mi Piace
4

This is a little bit tricky, I had a look at this just now. Basically we are always downloading from S3 with a presigned URL if we are doing a “force download”, which is what happens when we are clicking on the attachment link or clicking on the Download button on an image. This is so the appropriate content-disposition headers can be added:

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

I do not think it is possible to make the CDN URL behave in this way? The CDN URL for images is only used when displaying them inline, not when downloading them. Also in the case of secure images and attachments which have a private ACL the presigned URL must always be used.

2 Mi Piace
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
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.