tutorial - Permiso Django por objeto para su propio modelo de usuario

tutorial django

Question

Implementé mi propia clase de modelo de usuario de la siguiente manera. Tenga en cuenta que NO está personalizando el modelo auth.User de django. Soy nuevo en este conocimiento de permisos de objetos y especialmente en este modelo de Usuario autodefinido que se requiere en mi proyecto.

¿Podría dar un ejemplo de agregar permiso por objeto en este caso? Muy apreciado.

from django.contrib.auth.models import AbstractBaseUser, PermissionsMixin

class CustomUser(AbstractBaseUser, PermissionsMixin):
         email = models.EmailField(max_length=40, unique=True)
         //.... other fields are omitted

class Article(models.Model):
    title = models.CharField(''title'', max_length=120)
    body = models.TextField(''body'')
    author = models.ForeignKey(CustomUser)

Ahora, el permiso del objeto entra en juego. Cada usuario puede crear / actualizar / eliminar / ver sus propios objetos de artículos, pero SÓLO ver los artículos de otros sin el permiso para actualizarlos / eliminarlos.

De los documentos de django, el permiso de nivel de modelo no se aplica aquí. Si el artículo recibe permiso de actualización de nivel de modelo, todos los usuarios pueden actualizar el artículo de los demás.

Entonces, descubrí al django-guardián. Sin embargo, parece que no hay esperanza para este modelo de Usuario Personal autodefinido, ya que depende en gran medida del modelo de auth.User de Django.

https://django-guardian.readthedocs.org/en/v1.2/userguide/custom-user-model.html

ACTUALIZAR:

1. Mi caso está subclasificando AbstractBaseUser en lugar de AbstractUser;
2. Esto no es para el administrador, sino solo para mi lógica de código back-end;
3. No estoy utilizando la API REST de Django aquí, pero si la API REST es correcta, por favor dé un ejemplo.

Answer 1

En la página de documentación que ha publicado, también se indica:

Básicamente, si subclasificamos AbstractUser o definimos la relación many-to-many con auth.Group (y proporcionamos los grupos de nombres relacionados), estaríamos bien.

Como esto es lo que está haciendo, debe establecer AUTH_USER_MODEL como está escrito en la documentación de Django (también vea el ticket y el código de confirmación para la compatibilidad con Django 1.5).

Answer 2

Los permisos de nivel de objeto no están integrados en Django, incluso cuando se usa el modelo de auth.User estándar auth.User . Pero la base está ahí en que PermissionsMixin de Django define el método has_perm , que acepta una instancia modelo. Django no hace nada por defecto, pero puedes.

El método has_perm efectivamente has_perm el trabajo duro a los has_perm autenticación registrados. De modo que puede crear un backend de autenticación personalizado específicamente para realizar sus comprobaciones de permisos a nivel de objeto. No necesita manejar realmente la autenticación. Puede ser tan simple como un método único en una clase básica. Algo como lo siguiente (no probado) es todo lo que necesita:

class ObjectPermissionsBackend(object):

    def has_perm(self, user_obj, perm, obj=None):
        if not obj:
            return False # not dealing with non-object permissions

        if perm == ''view'':
            return True # anyone can view
        elif obj.author_id == user_obj.pk:
            return True
        else:
            return False

Dile a Django que use tu backend personalizado usando la configuración AUTHENTICATION_BACKENDS . En settings.py:

AUTHENTICATION_BACKENDS = (''django.contrib.auth.backends.ModelBackend'', ''path.to.ObjectPermissionsBackend'')

Luego, en tu código:

if user.has_perm(''edit'', article_instance):
    # allow editing

Consulte https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#custom-users-and-permissions y https://docs.djangoproject.com/en/1.8/topics/auth/customizing/ # especificación-autenticación-backends

Answer 3

Termino usando el permiso basado en lógica por objeto para que no altere mi base de datos. Son las reglas django las que soportan mi vista basada en clase. Recuerde anular el campo redirect_field_name, de lo contrario, terminará con un bucle de redirección si los usuarios han iniciado sesión.