Desarrollo de Python
  1. Desarrollo de Python
  3. Cómo separar usuarios (modelos) por administradores y clientes en Django
Intereting Posts
sql “LIKE” equivalente en la consulta de django Homografía abierta para encontrar coordenadas xy globales a partir de coordenadas xy pixel Python- ¿Cómo uso re para hacer coincidir una cadena completa? Las pandas convierten datetime con una columna de zona horaria separada Sqlalchemy: la subconsulta en FROM debe tener un alias Objeto inmutable de Python desde dentro de la función. Carga de archivos adjuntos a la API de Salesforce a través de Beatbox, Python Scipy.optimize.minimize SLSQP con restricciones lineales falla OSError: No existe tal archivo o directorio usando pytesser Validando una babosa en Django No puedo modificar mi script para delimitar el número de solicitudes mientras se raspa ¿Cómo importar funciones de otros proyectos en Python? Función de llamada basada en argparse. Mueva la “ayuda” a un grupo de argumentos diferente en python argparse Obtención de modelos de estadísticas para utilizar los errores estándar corregidos de heteroscedasticidad en las pruebas t de coeficiente

Cómo separar usuarios (modelos) por administradores y clientes en Django

Me gustaría separar a los usuarios de mi aplicación Django en dos clases:
– Admin (usuarios que usan Django admin) – heredar de AbstractUser
– Usuario (usuarios de clientes) – heredar de AbstractBaseUser

Quiero separar estos dos tipos de usuarios porque todos los campos de AbstractUser ( is_staff , is_superuser , groups , permissions ) son inútiles para los usuarios de mis clientes y para los permisos y grupos, solo quiero implementar algo diferente. Por eso, quiero usar AbstractBaseUser .

Pero para los usuarios de administración de django, la clase AbstractUser , es simplemente perfecta y particularmente con la función de permisos. 

 class Admin(AbstractUser): pass class Customer(AbstractBaseUser): pass

Pero ahora, ¿hay una manera de precisar el modelo de usuario usado Admin para el administrador de django solamente? Y usar el modelo de Customer para el rest de mis aplicaciones.

¿Tenía que implementar esto desde cero? 

 class MyUser(AbstractBaseUser): username = models.CharField(max_length=30, unique=True) first_name = models.CharField(max_length=30) last_name = models.CharField(max_length=30) email = models.EmailField() is_active = models.BooleanField(default=False) class Admin(MyUser, PermissionsMixin): is_staff = models.BooleanField(default=True) class Customer(MyUser): # specific fields pass

Con esta implementación, si configuro AUTH_USER_MODEL en User , los permisos no funcionarán porque el User no tiene permissions , is_superuser y is_staff .

Y si lo configuro como Admin , no podré autenticar a los Customers con django.contrib.auth .

Entonces, chicos, ¿tienen una solución a este problema?

La forma en que Django te ofrece parece ser mucho más flexible y adaptada para el futuro.

  1. Tiene un modelo de User incorporado, que puede anular. De todos modos, ese modelo tiene permisos, grupos, etc.
  2. Si necesita diferentes conjuntos de campos para diferentes tipos de usuarios, cree un OneToOne perfil OneToOne .
  3. El punto de separación entre sus administradores (en realidad, los usuarios del personal) y los clientes habituales es un atributo User.is_staff .

De esta manera, obtienes un montón de cosas interesantes (en comparación con dos modelos de usuario completamente diferentes):

  • Todo funciona fuera de la caja : los módulos contrib.auth y contrib.admin .
  • Punto de separación fácil de personalizar : simplemente anule el admin_site.has_permission() y aquí está.
  • Usted tiene la capacidad (pero no la obligación) de crear usuarios que sean clientes y administradores .
  • Puede asignar grupos y permisos (diferentes de los de sus administradores) a sus clientes. Incluso tú no lo necesitas ahora, quién sabe.

En cuanto a los inconvenientes. El único que ha señalado hasta ahora: sus clientes tendrán permisos (no utilizados por ahora). Bueno, como ellos (así como los grupos) son solo tablas separadas, los datos de sus clientes no tendrán un rendimiento de sobrecarga de almacenamiento.

Es decir, los gastos generales son insignificantes en comparación con los beneficios. Recomiendo encarecidamente quedarse con el modelo de User predeterminado de Django y extenderlo si es necesario.