google-app-engine amazon-s3 cloud-hosting hotlinking google-cloud-storage

Google Storage o Amazon S3 o Google App Engine BlobStore



google-app-engine amazon-s3 (4)

Cada vez que volvía a la codificación de servicios web estadísticos, tenía que generar imágenes y gráficos de forma dinámica. Las imágenes generadas dependerían del parámetro de solicitud, el estado del repositorio de datos y alguna información del encabezado.

Por lo tanto, si yo fuera usted, escribiría un servicio web REST para servir las imágenes. No es muy difícil. También es bastante delicado porque si no te gusta una dirección IP en particular, puedes mostrar una caricatura de la lengua de la mejilla (o un gif animado de OBL bailando samba mientras te bombardean) en lugar de la imagen para la solicitud de datos.

En su caso, usted verificará el referente (o referente) en el encabezado http, ¿verdad? Tengo dudas porque la gente puede y ocultará, borrará o incluso falsificará el campo de referencia en el encabezado http.

Por lo tanto, no solo verifique el campo de referencia, sino que también cree un campo de datos donde el valor cambie. El valor podría ser una simple coincidencia de valores.

Durante la guerra mundial, Roosevelt y Churchill se comunicaron a través del cifrado. Cada uno tenía una pila de discos idéntica, que de alguna manera contenía el mecanismo de cifrado. Después de cada conversación, ambos descartarían el disco (y nunca lo reutilizarían) para que la próxima vez que volvieran a hablar, buscaran el siguiente disco en la pila.

En lugar de una pila de discos, sus consumidores de imágenes y su proveedor de imágenes llevarán la misma pila de tokens de 32 bits. 32 bits le darían ~ 4 mil millones de períodos de diez minutos. La pila se secuencia aleatoriamente. Como es bien sabido que los "generadores aleatorios" no son realmente aleatorios y en realidad algorítmicos de una manera que pueda predecirse si se proporciona una secuencia suficientemente larga, debe usar un "generador aleatorio verdadero" o volver a poner la pila cada semana.

Debido a problemas de latencia, su proveedor aceptaría tokens del período actual, el último y el siguiente. Donde periodo = sector.

Su cliente ajax (probablemente gwt) en su navegador recibirá un token actualizado del servidor cada diez minutos. El cliente ajax usaría ese token para solicitar imágenes. El servicio de su proveedor de imágenes rechazaría un token obsoleto y su cliente ajax tendría que solicitar un token nuevo al servidor.

No es un método incombustible, pero es inastillable, por lo que podría reducir / desalentar la cantidad de solicitudes de spam (casi a cero, supongo).

La forma en que genero secuencias "verdaderamente aleatorias" es de nuevo rápida y sucia. Además, trabajo en una secuencia "aleatoria" generada algorítmicamente al dedicar unos minutos manualmente a tirar unas cuantas llaves de mono al reordenar o eliminar manualmente los valores de las secuencias. Eso arruinaría cualquier previsibilidad algorítmica. Tal vez, podría escribir un lanzador de llave inglesa. Pero un lanzador algorítmico de llave inglesa simplemente estaría agregando un algoritmo predecible por encima de otro algoritmo predecible que no reduce la previsibilidad general en absoluto.

Podría restringir aún más la situación obsesivamente empleando la concordancia de redundancia cíclica como un mecanismo de emparejamiento de token "encriptado" rápido y sucio.

Digamos que tienes un círculo dividido en 8 sectores equidistantes. Tendría un número binario de 3 dígitos para poder dirigirse a cualquiera de los 8 sectores. Imagina que cada sector se subdivide en 8 subsectores, de modo que ahora podrás abordar cada subsector con 3 bytes adicionales, lo que hace un total de seis bytes.

Usted planea cambiar el valor correspondiente cada 10 minutos. Su proveedor de imágenes y todos sus consumidores aprobados tendrán la misma pila de direcciones de sector. Cada diez minutos tiran la dirección del sector y usan la siguiente. Cuando un consumidor envía a su proveedor un valor coincidente, no envía la dirección de sector sino la dirección de subsector. De modo que siempre que su proveedor reciba una dirección de subsector que pertenezca al sector actualmente aceptado, el servicio del proveedor responderá con la imagen correcta.

Pero la dirección del subsector se reasigna a través de un algoritmo de secuenciación de ofuscación. de modo que cada dirección de subsector dentro del mismo sector no se parezca en absoluto. De esa manera, no todos los navegadores recibirían el mismo valor de token o un valor de token muy similar.

Digamos que tiene direcciones de sector de 16 bits y cada sector tiene direcciones de subsector de 16 bits, lo que constituye un token de 32 bits. Lo que significa que puede permitirse tener 65536 clientes de navegador concurrentes que llevan el mismo sector de token pero donde no hay dos token que tengan el mismo valor bajo de previsibilidad. Para que pueda asignar un valor de subsector de token para cada ID de sesión. A menos que tenga más de 65536 sesiones simultáneas en su servicio de proveedor de imágenes, no será necesario que dos identificadores de sesión compartan la misma dirección de token de subsector. De esa manera, a menos que un spammer tuviera acceso a equipos / instalaciones de identificación de sesión, no habría manera de que su proveedor de imágenes pudiera recibir spam, excepto mediante un ataque de denegación de servicio.

La baja capacidad de previsión significa que hay una baja probabilidad de que un fisgonista o espía confeccione un token aceptable para enviar correo no deseado al servicio de su proveedor de imágenes.

Ciertamente, los robots normales no podrían obtenerlo, a menos que realmente hayas ofendido al grupo ANÓNIMO y hayan decidido enviar correo basura a tu servidor por pura diversión. E incluso entonces, si hubiera lanzado llaves de monos en la pila de direcciones del sector y en los mapas del subsector, sería muy difícil predecir el siguiente token.

Por cierto, la concordancia de redundancia cíclica es en realidad una técnica de corrección de errores y no tanto una técnica de encriptación.

Voy a construir un sitio usando Google App Engine. Mi sitio público contiene miles de imágenes. Quiero almacenar estas imágenes en la nube: Google Storage o Amazon S3 o Google App Engine BlobStore. El problema es la imagen en caliente.

  1. En cuanto al almacenamiento de Google, busqué en Google y no puedo encontrar una manera de evitar el enlace en caliente de la imagen. (Aunque me gusta mucho su herramienta de línea de comandos gsutil)

  2. Amazon S3 tiene "Autenticación de cadena de consulta" que genera urls de imágenes caducadas. Pero esto es muy malo para SEO, ¿no? Cambiar constantemente la URL tendría efectos bastante negativos, ya que demora más de un año obtener una imagen y su URL relacionada en Google Images. Estoy bastante seguro de que cambiar esta URL tendría un efecto negativo inmediato cuando GoogleBot se presente para saludar. ( ACTUALIZACIÓN: una mejor manera de prevenir el enlace de imagen en Amazon S3 mediante la referencia es mediante la Política de Bucket. Detalles aquí: http://www.naveen.info/2011/03/25/amazon-s3-hotlink-prevention-with-bucket-policies/ )

  3. ¿Google App Engine BlobStore? Tengo que subir las imágenes a través de Interfaces Web manualmente y también genera urls cambiantes . ( Actualización: debido a mi ignorancia acerca de Blobstore, cometí un error. Al usar el motor de aplicaciones de Google BlobStore, puedes usar cualquier url para servir la imagen que deseas ) .

Lo que necesito es una protección de referencia simple: Mostrar solo la imagen cuando la referencia es mi sitio.

¿Hay alguna forma mejor de prevenir el hotlinking de la imagen? No quiero declararme en bancarrota debido al costo extremadamente alto del ancho de banda de la nube.

ACTUALIZAR:

Aún difícil elegir entre los tres, cada uno de ellos tiene sus pros y sus contras. BlobStore parece ser la elección definitiva.

Una versión más simple del ensayo de geek, cree un controlador en el motor de Google Apps para obtener y almacenar las imágenes. Puede modificar sus encabezados para especificar png o lo que sea, pero está devolviendo la imagen desde otra ubicación. Luego, puede examinar la información de referencia de su solicitud en el controlador y tomar las medidas adecuadas si alguien está tratando de acceder a esa imagen "hotlinked". Por supuesto, debido a que nunca expone la imagen real, sería imposible establecer un enlace activo. =)

La opción más fácil sería usar el blobstore. Puede proporcionar la interfaz de carga que desee (depende de usted escribirla) y Blobstore no restringe sus URL de descarga, solo las de carga. Puede servir imágenes de blobstore en cualquier URL simplemente estableciendo los encabezados apropiados, o puede usar get_serving_url para aprovechar el soporte de servicio de imágenes rápido incorporado, que genera URL crípticas pero consistentes (pero no le permite realizar verificaciones de referencia) .

Sin embargo, sugeriría considerar si este es un problema real y práctico al que te enfrentas. El ancho de banda consumido por unas pocas imágenes de enlace directo es bastante mínimo para los estándares de hoy, y no es una práctica particularmente común en primer lugar. Como @sharth señala en los comentarios, es probable que también afecte el SEO, ya que la búsqueda de imágenes tiende a mostrar imágenes en sus propias ventanas además de vincularse a la página que las hospedó.