2011-05-20 13 views
6

Estoy trabajando en un proyecto de comercio electrónico algo de Django, donde, brevemente, tengo un cliente y un modelo de comerciante. El modelo de comerciante está asociado con un modelo de MerchantStore que es de alguna manera "complicado", que tiene una plétora de m2m y relaciones de clave externa para varios modelos.Exponer django admin a los usuarios. ¿Perjudicial?

Siguiendo la solución en este post y no teniendo suficiente "tiempo" para realizar una implementación personalizada, decidí dejar que cada comerciante sea un "miembro de cosas" y personalizar su tienda a través de la interfaz de administración. De cource creé un nuevo grupo con los permisos apropiados.

Sin embargo, surgen algunas preguntas:

1) ¿Se considera dañino? ¿Hay alguna amenaza de seguridad asociada?

2) ¿No es esta la mejor manera de hacerlo si no tienes suficiente tiempo de todos modos?

Respuesta

5

No, no lo consideraría dañino. El "Zen de administración" como se describe en el djangobook de Apress parecía implicar una asunción de confianza como parte de la "filosofía" del administrador, y emparejado con el consejo "admin no es su aplicación" repetido a menudo, yo también era asustado al principio y piensa que la documentación de Django podría señalar casos de uso previstos y viables.

Por favor, ver a mi casi idéntica pregunta Django AdminSite/ModelAdmin for end users?

De la respuesta de Jordan (quien me dio la recompensa):

No hay nada intrínsecamente especial acerca administrador. Se comporta como cualquier otra vista . Así que si está utilizando permisos para determinar el acceso (por ejemplo, si se establece .is_staff de un usuario a True pero les dan acceso sólo a permisos específicos), entonces será igual de seguro a cualquier punto de vista es posible que crear ese usa permisos para determinar el acceso.

...

Las personas que escribieron django.contrib.admin no lo escribió con la suposición de que cualquier persona con un is_staff = True se podía confiar en que tanto como un superusuario, o era estúpida suficiente para nunca echar un vistazo al código fuente de una página web.Aunque se recomienda escribir sus propias vistas, sigue siendo una interfaz sólida.

También tenga en cuenta la actualización de seguridad relativamente reciente de Django http://www.djangoproject.com/weblog/2010/dec/22/security/ respecto a los parámetros de cadena de consulta en las listas de objetos.

Dicha actualización (cita: "un atacante con acceso al administrador [...]") es una clara indicación de que la implementación del sistema de permisos por parte del administrador se analiza constantemente.

+0

¡Bien, entre sí y no, este último es más conveniente para mí! – hymloth

5

Sí, esto se considera "nocivo", principalmente debido a las consideraciones de diseño de los desarrolladores de Django. El administrador gira en torno a un concepto de "usuarios de confianza". En otras palabras, si alguien es un miembro del personal (y por lo tanto tiene acceso al administrador), presumiblemente tienen suficiente confianza para no preocuparse por las violaciones de seguridad. Ahora, en verdad, podrías bloquearlos de porciones con las que no deben meterse (como lo has hecho), pero el punto es que Django no ofrece garantías en esta área. Probablemente no tenga ningún problema, en realidad, pero podría.

Irónicamente, creo que he pasado más tiempo en mi vida personalizando el administrador de Django de lo que me hubiera llevado construirlo desde cero. Es curioso cómo va eso. En cualquier caso, me gustaría utilizar andamios en Ruby on Rails. Es una manera rápida de obtener algo en vivo, pero el objetivo es reemplazarlo lo antes posible.

+0

Entonces, en otras palabras, ¿podría un super y malicioso, por ejemplo, hacker, perder el control y causar un daño grave a todo el sistema? ¿Es esto posible técnicamente y qué tan fácil de lograr? ¿El sistema de privilegios no es concreto al igual que el sistema de permisos de Linux? – hymloth

+0

Bueno, en lo que se refiere a la "piratería", realmente no hay más riesgo que el administrador normalmente tiene en condiciones óptimas. La verdadera preocupación es exponer algo, ya sea por accidente o por negligencia, a usuarios que no deberían verlo en primer lugar. El administrador de Django está diseñado para el personal, personas dentro de su organización en las que confía y a las que ha otorgado privilegios. Ir más allá de ese alcance significa inherentemente que se está arriesgando. La línea estándar es no permitir que los usuarios "normales" accedan al administrador. Puede optar por ignorar eso, pero lo hace bajo su propio riesgo. –