2010-09-30 19 views
5

Tengo un sitio que permite al usuario descargar ciertos archivos. Sin embargo, quiero mantener un conteo de descargas para cada archivo, por lo que ir de la manera habitual al poner los archivos estáticos en un subdominio diferente y dejar que apache haga el trabajo pesado no es una forma tan buena como HttpResponse. Redirigir al usuario a un subdominio no es bueno porque entonces el usuario 've' la URL de descarga adecuada y, por lo tanto, puede descargar el archivo sin aumentar el conteo de descargas. Podría simplemente construir una vista que luego sirva() el archivo, pero me preocupa que "big fat disclaimer". ¿Cómo implementarías esto? Estoy bastante seguro de que no soy el único con ese problema.Sirviendo archivos estáticos con lógica en django (manteniendo una cuenta de descarga)

Sobre la plataforma: Estoy usando apache y mod_wsgi.

Gracias

Respuesta

1

La respuesta de psj es definitivamente una opción viable. Otra opción que debes investigar es poner un servidor de proxy inverso en frente de apache como Perlbal que admite encabezados "X-REPROXY-URL".

Una vez que tenga instalado el servidor de proxy inverso, en lugar de enviar al usuario una respuesta de redirección, puede enviar una respuesta con el encabezado "X-REPROXY-URL" establecido a una URL donde el servidor proxy puede acceder pero el usuario no puede. El servidor proxy leerá en el archivo desde la ubicación que envió en el encabezado y luego lo publicará en su cliente. Lo harán de una manera eficiente y dado que todo su servidor de aplicaciones Django necesita enviar es una respuesta con un conjunto de encabezado, es libre de manejar otra solicitud.

0

Lo hice con Django de venta libre no hace a tiempo. Le permite realizar un seguimiento de los recuentos en el administrador. http://github.com/svetlyak40wt/django-counter/

+0

esperaba una respuesta más general ya que mantener un conteo de descargas no será la única lógica :) – niklasfi

5

Hemos implementado un sistema en el que necesitábamos controlar el acceso de descarga a archivos estáticos (grandes), naturalmente no queriendo que Django los sirviera solo. Se nos ocurrió un esquema mediante el cual la aplicación Django, después de validar que el usuario podía descargar el archivo (o incrementar un contador, en su caso), crearíamos un enlace simbólico al archivo, al que tenía acceso Apache (tenga cuidado: asegúrese de que la indexación de directorios esté desactivada, etc.), y luego redirija al usuario a ese enlace simbólico para que Apache lo sirva.

Tenemos un cronjob de "limpieza" que limpia el enlace simbólico un minuto después de su creación, por lo que si quieren volver a descargarlo, tienen que pasar por Django y contarlo nuevamente. Ahora, en teoría, podrían descargarlo más de una vez en ese momento, pero ¿es probable que eso suceda? Podrías limpiar más de cada minuto: Apache solo necesita el enlace simbólico para existir al comienzo de la descarga, no durante todo el proceso.

Me gustaría saber cómo otros abordan este problema, ya que estoy de acuerdo con el OP en que es un escenario común.

+0

esto suena como una buena idea, pero me gustaría mantener un diseño de url decente y permitir que el usuario descargue un archivo dos veces desde la misma ubicación – niklasfi

+0

Claro, pero este modelo aún lo admite. La URL canónica del archivo es la URL controlada por Django, que es coherente y decente, etc., y la única URL que el usuario ve. La redirección al enlace simbólico servido por Apache es más un "detalle de fontanería" que el usuario no nota: el navegador sigue la redirección de forma transparente. – psj

Cuestiones relacionadas