Le problème est que le CDN affiche un comportement cassé, ce que vous ne souhaitez absolument pas. Seul le non-CDN fonctionne correctement, c’est-à-dire que lorsque vous cliquez sur « télécharger », quelque chose se télécharge.
Ah oui, alors il faut le corriger.
C’est juste. Y a-t-il des exemples de personnalisation du lightbox que je pourrais utiliser comme point de départ ?
Ceci n’est absolument pas facile à pirater, comme le montre :
Vous devriez parcourir Magnific Popup: Responsive jQuery Lightbox Plugin et vérifier s’il est possible de le reconfigurer dynamiquement.
Dommage, je vais voir si je peux trouver une solution.
Par simple curiosité, pourquoi Discourse opte-t-il pour une action « télécharger » plutôt que pour « voir en taille réelle » ici ? Du point de vue de l’utilisateur, il semblerait que la taille réelle soit une action plus courante ?
Je pensais qu’il s’agissait d’un problème MIME, mais en examinant l’en-tête, il se pourrait que ce soit :
x-download-options: noopen
Ce qui empêche l’ouverture d’un fichier lors du téléchargement. J’espère que Sam pourra clarifier cela.
C’est à @codinghorror de décider. Je suppose que c’est un moyen de conserver proprement le nom de fichier original du téléchargement, ce qui importe à certaines personnes. De plus, cela semble être ce que Flickr aime faire.
Je ne pense pas que nous allons toucher à tout cela. Nous ferons simplement en sorte que l’application fasse proxy via une route dédiée ou quelque chose de similaire. Le nombre de personnes cliquant sur « télécharger » étant minuscule, un contournement du CDN pourrait être acceptable ici. Quoi qu’il en soit, @pmusaraj pourra déterminer la meilleure option. D’après ce que je comprends, soit nous devons demander à AWS de nous fournir une URL signée avec une disposition de contenu spéciale, soit nous devons faire proxy du fichier. Dans les deux cas, cela impliquera un contournement du CDN S3. Si nous faisons proxy via l’application, au moins nous pourrons utiliser le CDN de l’application.
Après un peu plus de lecture, il semble que content-disposition: attachment; et x-download-options: noopen soient responsables de ce comportement.
Je comprends que c’est le comment, et non le pourquoi. Si c’est pour des raisons de sécurité, cela a parfaitement du sens.
Cette PR devrait résoudre le problème en :
- ajoutant un attribut
data-download-hrefau lien de téléchargement de la lightbox lorsque les uploads S3 sont activés - utilisant une nouvelle URL courte avec le paramètre
dl=1, qui permettra au contrôleur de générer une URL S3 signée avec la bonne disposition de contenu et le bon nom de fichier
Autrement dit, le lien de téléchargement dans la lightbox ressemblera désormais à /uploads/short-url/mTGbg4Ld2iBYAbfTvEjGXP2LtVm.pdf?dl=1, qui redirigera vers une URL S3 signée avec content-disposition: "attachment; filename=original.png".
Je pense que c’est l’option la plus simple et la plus directe ; le proxy via l’application serait un peu moins efficace, car le fichier téléchargé devrait passer de S3 au serveur Discourse, puis au client.