template - loginview django

¿Django AdminSite/ModelAdmin para usuarios finales?

Question

No todo el software tiene la necesidad de una interfaz de administración para "productores de contenido" a la izquierda y un sitio para "visitantes / miembros" a la derecha.

A menudo se dice que "el administrador no es su aplicación" (consulte, por ejemplo, la respuesta aceptada (marzo de 2009) ).

No pude encontrar tal limitación mencionada explícitamente en la documentación de Django. Parece haber una suposición subyacente de lo anterior: " una interfaz poderosa y lista para la producción que los productores de contenido pueden usar de inmediato para comenzar a agregar contenido al sitio ", pero se anticipan diferentes niveles de acceso, incluso se mencionan en las Preguntas frecuentes . ¿Y qué otro caso de uso para múltiples instancias de AdminSite de todos modos?

Actualmente estoy trabajando en un software que es principalmente una interfaz CRUD. Todos los usuarios deben estar autenticados, y la única diferencia entre los usuarios administradores y los clientes es que estos últimos solo pueden trabajar con "sus" objetos (y no tienen acceso a ciertos modelos como "Usuario", etc.). Por cierto, "su" en mi caso no está relacionado con quién creó el objeto, sino con qué "Compañía" está asociada .

¿Hay alguna razón convincente para no limitarse a la interfaz de administración y configurar el cóctel de permisos correcto? ¿Se puede confiar en los permisos de ModelAdmin? ¿Por qué no llamar a todos los usuarios registrados "personal"?

Para las vistas tradicionales que no son de administración, me veo reescribiendo lo que parece que ya existe: un ModelForm es un buen comienzo, pero la funcionalidad CRUD y los filtros dependientes del tipo (incluida la fecha detallada) no son componentes fácilmente disponibles. La funcionalidad del administrador ya proporciona la gran mayoría de las funciones que necesitan los usuarios finales, y la personalización de los campos / filtros / plantillas, etc. es suficiente para mis necesidades. Obviamente, cuando agrego una nueva función, por ejemplo, la visibilidad de su botón y el acceso a las vistas correspondientes necesita una verificación de permisos. No estoy preocupado por eso. Solo tengo curiosidad por saber si, en un caso como este, la funcionalidad Admin está cubierta adecuadamente por su conjunto de permisos incorporado. ¿Alguna experiencia con eso?

ACTUALIZACIÓN: Lo sentimos, la parte principal de esta pregunta parece poco clara. No me preocupan mis personalizaciones, me preocupa confiar en la aplicación de administración existente y su implementación de permisos. Ver también comentarios a Daniel y FallenAngel.

Answer 1

Si el administrador, personalizado usando los ganchos provistos, si es necesario, satisface sus necesidades, entonces, por supuesto, no hay razón para no usarlo. El punto es que debe ser realista acerca de lo que proporciona y lo que no proporciona, y asegúrese de que no va a comenzar a necesitar una funcionalidad que solo sea posible fuera del administrador. He estado por ese camino, y no es bonito.

Answer 2

Tenemos un sistema que simplemente se ejecuta como usted pidió.

El programa tiene un inicio de sesión de usuario básico, que es el sitio básico y utiliza vistas y plantillas escritas a mano (como era necesario) ... Existe una parte del Cliente , que es la página de administración básica con derechos de acceso limitados. Y hay admin quien soy yo y gente como yo.

La lógica es que los administradores son personas que trabajan en la empresa, que pueden tener todos los permisos de acceso (superusuarios, como dice sjango) o acceso limitado a las aplicaciones, pero pueden ver todos los registros de bases de datos relacionados de aquellos a los que tienen acceso. Los clientes son personas que vendemos nuestro programa, tienen acceso limitado al administrador y solo pueden ver los registros relacionados con ellos. Los usuarios son clientes de nuestros clientes ...

En ese punto, los permisos de django no son suficientes, porque nuestro cliente debe ver que los registros pertenecen a su cuenta, mientras que un administrador estándar puede ver todos los registros. Estos dos pueden llegar a las solicitudes de acuerdo a sus permisos. El superusuario puede ver y hacer cualquier cosa ...

Para la solución, en lugar de usar la aplicación del sitio django (que nunca usé y no tengo mucha información) creamos un modelo que extiende al usuario de Django, que tiene un campo como el rol que el rol del usuario es el administrador del sistema, luego puede ver todo ( si es superusuario, de lo contrario, utiliza los permisos de forma normal) ... Si no, puede acceder a los registros relacionados con su sitio web (la Compañía en su situación).

Por lo tanto, casi cada tabla de base de datos debe tener una compañía propietaria que define la clave extranjera del registro relacionado.

Por eso, puede filtrar registros que pertenecen a una empresa específica si es necesario ...

En mis modelos, tengo Kullanici que hereda el modelo de usuario.

class Kullanici(User):
    rol = SmallIntegerField()# 1 if system admin, 2 if cusotmer etc...

Luego, escribo algunos métodos para anular los métodos de administración, como: ModelAdmin.save y modelAdmin.queryset que realizan la siguiente comprobación ...

#override admin queryset method
def override_queryset(obj, req):
    qs = super(type(obj), obj).queryset(req)
    kullanici = Kullanici.objects.get(id=req.user.id)
    if kullanici.rol == 10:
        return qs
    return qs.filter(site=kullanici.site)

Entonces, cuando un usuario accede a la vista de lista de una aplicación, solo ve los sitios relacionados con él, no se mostrarán otros registros, o recibirá un error de permiso si intenta ir a un registro que pertenece a otro sitio. Estos son todos los controles de bajos Django, por lo que puede estar seguro de que no alcanzarán el registro de hormigas y no deberán hacerlo.

Debe anular todos los métodos de administración que requieren que el filtro pertenezca al cliente.

Para mayor limitación, utilicé una función para mostrar / ocultar los campos del modelo. En el archivo admin .py:

class SomeModelAdmin(ModelAdmin):
    exclude= []
    def changelist_view(self, request, extra_context=None):
        extra_context = {''exclude'':[''field1'',''field2'']}
        return get_admin_listview(self, request, extra_context)


def get_admin_listview(obj, req, extra):
system_admin = Kullanici.objects.get(id=req.user.id).rol == 1
if not system_admin:
    if ''exclude'' in extra.keys():
        for key in extra[''exclude'']:
            if key not in obj.exclude:
                obj.exclude.add(key)

da una lista de los nombres de los campos que se ocultarán, y los ocultará si el usuario no es administrador del sistema ...

Los handycaps son, el almacenamiento en caché del administrador de django puede causar, lo que me sucedió una o dos veces en 8 meses. Otra parte importante es que no puede limitar los filtros de administración, por lo que si tiene un filtro que requiera acceso limitado, no puede filtrar las claves de filtro. Puede mostrarlo con todas las opciones o simplemente no usarlo.

Si este enfoque resuelve su problema, puedo escribir una información más detallada ...

ACTUALIZACIÓN: Sí, el sistema de permisos es simple y seguro, si verifica el código fuente del decorador requerido_requirido del último código troncal ...

La lógica es simple, el usuario tiene permisos relevantes, la vista relacionada se ejecuta. De lo contrario, la vista relacionada o el código no se ejecutan en absoluto. Por lo tanto, los permisos proporcionan suficiente seguridad para el administrador de Django. El control de permisos se puede utilizar tanto a nivel de vista como a nivel de plantilla.

Un punto que debe ser cuidadoso son las vistas escritas a mano, donde el código inseguro puede causar problemas graves, pero se trata de su codificación, y este es el tipo de riesgo de seguridad que enfrentará en cada framework y lenguaje de programación ...

El último punto del problema es el mecanismo de filtrado de las páginas de visualización de django y admin. Ya que casi todos los filtros de administración utilizan GET para filtrar datos, y pasa los ID a las URL para mostrar un registro específico. La parte de seguridad del libro de django muestra información básica sobre posibles problemas de seguridad y cómo los maneja django ... Por otro lado, la actualización de seguridad del 22 de diciembre de 2010 muestra una vulnerabilidad tan importante, que requiere suficiente información sobre la estructura del modelo.

Answer 3

No hay nada inherentemente especial acerca de admin . Se comporta como cualquier otra vista. Por lo tanto, si usa los permisos para determinar el acceso (por ejemplo, si configura el .is_staff un usuario .is_staff True pero le otorga acceso solo a permisos específicos), será igual de seguro para cualquier vista que pueda crear que use permisos para determinar el acceso.

De la misma manera, la personalización que proporcione a un ModelAdmin dará como resultado una implementación que es igual de segura que cualquier cosa que pueda escribir.

Si escribe un has_change_permission personalizado para su modelo, por ejemplo:

def has_change_permission(self, request, obj=None):
    return obj.company == request.user.get_profile().company

Esto va a funcionar . No va a ocultar simplemente un botón; va a bloquear completamente este objeto de ser editado.

Las personas que escribieron django.contrib.admin no lo hicieron con la suposición de que cualquiera con un is_staff = True podía confiar tanto como un superusuario, o era tan estúpido como para nunca mirar el código fuente de una página web. Aunque se recomienda escribir sus propias vistas, sigue siendo una interfaz robusta.

Consulte, por ejemplo, esta sección del código fuente que genera una excepción de PermissionDenied si intenta acceder a change_view sin permiso para editar el objeto real:

def change_view(self, request, object_id, extra_context=None):
    "The ''change'' admin view for this model."
    model = self.model
    opts = model._meta

    obj = self.get_object(request, unquote(object_id))

    if not self.has_change_permission(request, obj):
        raise PermissionDenied

    # view continues...

Entonces, incluso si alguien has_change_permission la URL correcta para editar un objeto dado, siempre que haya implementado correctamente has_change_permission se le negará el acceso al usuario.