Cómo proxy de archivos de S3 a través de la aplicación de rieles para evitar la sanguijuela?

Para evitar hot-linking, S3 bandwidth leeching, etc. Me gustaría hacer que mi depósito sea privado y servir los archivos a través de una aplicación de Rails. El concepto en general suena muy fácil, pero no estoy del todo seguro de qué enfoque sería el mejor para la situación.Cómo proxy de archivos de S3 a través de la aplicación de rieles para evitar la sanguijuela?

Estoy usando clip para la gestión general de activos. ¿Hay alguna forma de incorporar este tipo de proxy?

En general, puedo analizar fácilmente las URL del clip y señalarlas a mi propio controlador. ¿Qué debería pasar desde este punto? ¿Debo simplemente usar Net :: HTTP para descargar la imagen y luego servirla con send_data? En el medio quiero registrar el referer y establecer los encabezados de Control-Cache adecuados, ya que tengo un proxy inverso en frente de la aplicación. Es Net :: HTTP + send_data de manera razonable en este caso?

¿Quizás ideas completas son realmente malas por alguna razón que no conozco en este momento? Yo en general creo que reveling los enlaces directos a S3 cubo pública es peligrosa y el rendimiento en algunos problemas graves en el caso de sanguijuela/caliente que une ...

Actualización:

Si tiene alguna otra idea que puede reduzca la factura de S3 y evite el ligamiento de enlaces calientes de todos modos, comparta, incluso si no están directamente relacionados con los rieles.

Fuente

2010-10-27 mdrozdziel

¿Actualmente estás teniendo un problema con leeching? Sería reacio a hacer algo que ralentizará drásticamente mi aplicación, solo para resolver un problema que pueda tener en el futuro. – mikerobi

No se trata solo de resolver un posible problema. Simplemente no quiero despertarme un día con una abrumadora factura de S3, que no puedo pagar ... No estoy tan seguro, si esto ralentizará la aplicación "dramáticamente", cuando los activos se mantendrán en memcache/reverse apoderado. – mdrozdziel

Probablemente evitaría hacer esto, al menos hasta que no tenga otra opción.

Debe tener en cuenta que probablemente también agregue a la factura de ancho de banda si descarga la imagen cada vez. Además, al procesar cada imagen a través de un script, también necesitará más CPU y RAM para hacerlo. No es la mejor perspectiva - IMHO.

Probablemente enable the access logs para Amazon S3 y escribir una herramienta pequeña para analizar el uso y cambiar los permisos en el cubo/objeto en caso de que el uso se vaya al techo. Ejecutar esto como un cronjob cada 10 minutos más o menos y debe ser guardado?

También podría usar s3stat. También ofrecen un plan gratuito.

Editar: Según mi recomendación para Barniz, estoy agregando un enlace a a blog entry about preventing hotlinking using Varnish.

Fuente

2010-11-02 02:37:09 Till

Conozco las desventajas, por supuesto, por eso estoy pidiendo una idea para la solución. En general, no es tan malo. Tenga en cuenta que las imágenes se pueden cobrar ampliamente en la mayoría de los casos. Mientras hacía algunas búsquedas, llegué a la conclusión de que la forma más efectiva sería un proxy inverso frente a la aplicación S3 en lugar de los rieles. También puedo hacer todo lo que esté a mi alcance: verificar el referer, hacer un extenso análisis de registro. Tal front end redirigiría dramáticamente la cuenta S3 y el rendimiento no debería ser menor al final. – mdrozdziel

Sí, eso suena bien, recomendaría el barniz. :) Solo tenga en cuenta que, aunque las imágenes están almacenadas en la memoria caché, también ejecuta una configuración más _complicada_ agregando otro servicio. Y posiblemente también requiera más potencia de procesamiento (por ejemplo, una instancia o al menos recursos) para el proxy. – Till

Use (un cubo privado | archivos privados) y use URL firmadas para los archivos almacenados en S3.

La firma incluye un tiempo de caducidad (por ejemplo, 10 minutos a partir de ahora, lo que sea que desee establecer), así como un hash criptográfico. S3 se negará a entregar los archivos si la firma no es válida o si ha expirado el tiempo de caducidad.

Esto es útil porque solo usted puede crear URL válidas para sus archivos privados en S3, y puede controlar por cuánto tiempo las URL siguen siendo válidas. Esto evita las sanguijuelas, porque los leechers no pueden firmar sus propias URL y, si obtienen una URL que usted firmó, esa URL caducará muy pronto y luego no se podrá usar.

Fuente

2010-12-06 19:39:27 yfeldblum

Como no había una respuesta de tuercas y tornillos, aquí hay una pequeña muestra de código de cómo transmitir un archivo que está almacenado en S3.

render :text => proc { |response, output| 
    AWS::S3::S3Object.stream(path, bucket) do |segment| 
    output.write segment 
    output.flush # not sure if this is needed 
    end 
}

Dependiendo de su servidor web esto puede (mestizo) o no (WEBrick) de trabajo, por lo que no se frustre demasiado si no corriente en el desarrollo.

Fuente

2011-07-22 22:07:42 Justin

URL previamente firmadas Proporcionar temporales:

def show 
     redirect_to Aws::S3::Presigner.new.presigned_url(
     :get_object, 
     bucket: 'mybucket', 
     key: '/folder/file.pdf' 
     expires_in: 60) 
    end

S3 sigue distribuyendo el contenido para que la descarga de la obra de rieles (que es muy lento en ello), maneja el almacenamiento en caché de HTTP, las operaciones de la cabeza, y utiliza Amazon CDN .

Fuente

2016-04-21 18:58:23

Cómo proxy de archivos de S3 a través de la aplicación de rieles para evitar la sanguijuela?

Respuesta

Cuestiones relacionadas