URL CDN S3 non utilisée sur les téléchargements non image

Contribuer Bug
1

Cela pourrait être lié à S3 CDN URL ignored when uploading into posts.

Au début, je pensais avoir manqué une configuration, mais le problème est reproductible ici sur Meta :
https://meta.discourse.org/uploads/short-url/dw1U4hctATusBlHsUmWQXeme66j.csv (téléchargé ici) renvoie une redirection 302 vers
//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/5/e/5ebb2cfb8cc907e8e8f7c6559a72d2f4a8ba2f8f.csv

Ne devrait-elle pas rediriger vers https://d11a6trkgmumsb.cloudfront.net/original/3X/5/e/5ebb2cfb8cc907e8e8f7c6559a72d2f4a8ba2f8f.csv à la place ?

5 « J'aime »
S3 Uploads - Using CDN for PDFs?
2

Hmm, il se peut qu’il y ait un problème ici @martin, peux-tu enquêter ? Nous devrions probablement rediriger vers le CDN si possible.

5 « J'aime »
4

C’est un peu délicat, je viens d’y jeter un coup d’œil. En gros, lorsque nous effectuons un « téléchargement forcé », nous téléchargeons toujours depuis S3 en utilisant une URL signée. C’est ce qui se produit lorsque nous cliquons sur le lien de pièce jointe ou sur le bouton Télécharger d’une image. Cela permet d’ajouter les en-têtes content-disposition appropriés :

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

Je ne pense pas qu’il soit possible de faire en sorte que l’URL du CDN se comporte de cette manière ? L’URL du CDN pour les images n’est utilisée que pour les afficher en ligne, pas lors de leur téléchargement. De plus, dans le cas des images et pièces jointes sécurisées ayant une ACL privée, l’URL signée doit toujours être utilisée.

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

@martin concernant les liens de pièces jointes, je ne vois pas comment ils peuvent être configurés pour toujours « forcer le téléchargement ». Actuellement, lors du téléchargement d’un fichier non image, l’URL rendue résultante est une URL courte sans le paramètre ?dl=1 qui est résolu à la valeur de l’attribut url de l’upload correspondant (qui n’est pas une URL pré-signée et échoue également dans notre cas car l’URL n’est pas la cdn_url s3 mais une URL construite qui pourrait ne fonctionner que pour certains fournisseurs s3).

Existe-t-il un moyen de forcer systématiquement le téléchargement des pièces jointes, ou le comportement actuel est-il en fait un bug ?

1 « J'aime »
6

Pouvez-vous développer ici, utilisez-vous Amazon S3 ou un autre fournisseur ? Si oui, lequel ?

1 « J'aime »
7

Oui, il semble que j’utilise un fournisseur S3 non pris en charge (OVH Object Storage)

Avec une URL de point de terminaison de https://s3.de.ovh.cloud.net et une s3 cdn_url configurée sur https://storage.de.ovh.cloud.net/v1/<some-unique-user-id>/<the-bucket-name>

Lorsque les URL courtes sont résolues, Discourse utilise l’URL du point de terminaison pour construire l’URL résultante (ce qui échoue car elle n’inclut pas le bon ID utilisateur OVH - la partie de la s3 cdn_url).

Forcer les URL courtes à avoir dl=1 construirait cependant une presigned_url fonctionnelle, ce qui me conviendrait.

J’ai défini ces variables d’environnement (spécifiques à S3) dans le YAML du conteneur :

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 « J'aime »
8

Peut-être que cela sort du cadre de ce sujet, mais si le comportement actuel est intentionnel, comment ou où pourrait-on remplacer le rendu des URL courtes dans le frontend ? Je pense simplement à intercepter le processus de cuisson des articles, puis à ajouter le paramètre de requête aux URL courtes des pièces jointes. Je sais comment écrire des plugins JS pour Discourse, mais la plupart du temps, j’ai du mal à trouver le bon Widget pour « rouvrir » ou la fonction à remplacer.

9

Ok, j’ai trouvé l’endroit où la génération des pièces jointes Markdown est générée et, d’après ce que je comprends de l’API des plugins, on ne peut pas (facilement) la remplacer (je pense même qu’on ne devrait pas le faire).

Donc, mon idée initiale d’ajouter un paramètre ?dl=1 à ces URL semble être la mauvaise approche.

Concernant le fait de ne pas forcer le téléchargement pour les URL courtes résolues : si je comprends bien l’argument contre les ACL publiques sur les buckets S3, il faudrait soit :

  1. servir les fichiers de S3 via un CDN (irréalisable pour les pièces jointes, comme l’a souligné @martin, car nous pourrions ne pas être en mesure de définir correctement le nom de fichier pour le téléchargement dans ce cas)
  2. créer une URL pré-signée pour l’objet S3

Mais le comportement actuel ne fait ni l’un ni l’autre et s’attend à ce que le bucket S3 ait une ACL publique. C’est également le cas pour les fournisseurs S3 pris en charge (y compris Amazon), alors je me demandais pourquoi ne pas faire en sorte que l’option force_download dans Discourse.store.url_for soit définie par défaut sur true (https://github.com/discourse/discourse/blob/v2.8.0.beta11/app/controllers/uploads_controller.rb#L121) lors de la résolution des URL courtes pour les stockages S3 ?

1 « J'aime »
Configure an S3 compatible object storage provider for uploads
11

J’ai le même problème ici, ce que j’attends, c’est que le fichier derrière uploads/short-url soit téléchargé ou redirigé vers l’URL du CDN S3.

2 « J'aime »
12

Nous rencontrons le même problème avec Cloudflare R2, car il ne semble pas autoriser l’utilisation de l’URL S3 directe sans une URL pré-signée.
Et R2 ne prend pas en charge les ACL pour les buckets.

13

Il semble que Discourse ait récemment ajouté une option « Utiliser l’URL CDN pour tous les téléchargements » qui résout ce problème.