El problema es que la CDN está mostrando un comportamiento roto, que es exactamente lo que no quieres. Solo la no CDN funciona correctamente, ya que al hacer clic en “descargar”, algo se descarga.
Ah, sí, entonces deberíamos solucionarlo.
Tiene sentido. ¿Hay algún ejemplo de personalización del lightbox que pueda usar como punto de partida?
Esto no es nada fácil de hackear, según:
Tendrías que revisar Magnific Popup: Responsive jQuery Lightbox Plugin y ver si de alguna manera se puede reconfigurar sobre la marcha.
Qué pena, veré si puedo encontrar una solución.
Solo por curiosidad: ¿por qué Discourse opta por una acción de ‘descargar’ en lugar de ‘ver tamaño completo’ aquí? Desde la perspectiva del usuario, parecería que ver el tamaño completo es una acción más común.
Pensé que se trataba de un problema de MIME, pero al revisar la cabecera, podría ser:
x-download-options: noopen
Lo que impide que se abra un archivo al descargarlo. Espero que Sam pueda aclararlo.
Es decisión de @codinghorror. Supongo que es una forma de mantener limpiamente el nombre original del archivo subido, algo que a algunas personas les importa. Además, esto parece ser lo que Flickr suele hacer.
No creo que vayamos a tocar nada de esto; simplemente la aplicación hará de proxy en una ruta dedicada o algo similar. La cantidad de personas que hacen clic en “descargar” es mínima, por lo que un posible bypass del CDN podría ser aceptable aquí. De todos modos, @pmusaraj podrá determinar cuál es la mejor opción. Por lo que puedo ver, o bien debemos pedirle a AWS que nos proporcione una URL firmada con una disposición de contenido especial, o bien debemos hacer de proxy del archivo. En ambos casos implicará un bypass del CDN de S3. Si hacemos de proxy a través de la aplicación, al menos podremos usar el CDN de la aplicación.
Tras leer un poco más, parece que content-disposition: attachment; y x-download-options: noopen son los responsables de este comportamiento.
Agradezco que esa sea la forma en que sucede, no la razón. Sin embargo, si es por razones de seguridad, tiene todo el sentido del mundo.
Esta PR debería solucionarlo mediante:
- agregar un
data-download-hrefal enlace de descarga del lightbox cuando las cargas en S3 están habilitadas - la URL utilizada es el nuevo esquema de URL corta con un parámetro
dl=1que hará que el controlador genere una URL firmada de S3 con la disposición de contenido y el nombre de archivo correctos
En otras palabras, el enlace de descarga en el lightbox ahora se verá como /uploads/short-url/mTGbg4Ld2iBYAbfTvEjGXP2LtVm.pdf?dl=1, lo que redirigirá a una URL firmada de S3 con content-disposition: "attachment; filename=original.png".
Creo que esta es la opción más simple y directa; hacer proxy a través de la aplicación sería un poco menos eficiente, ya que el archivo descargado tendría que ir desde S3 al servidor de Discourse y luego al cliente.