Разрешение Django на объект для вашей собственной модели пользователя

я реализовал свой собственный класс модели пользователя следующим образом. Обратите внимание, что это не настройки Джанго auth.User модель. Я новичок в этом знании разрешений объекта и особенно в этой самостоятельной модели пользователя, которая требуется в моем проекте.

не могли бы вы привести пример добавления разрешения на объект в этом случае? Ценится.

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)

сейчас, разрешение объекта вступает в игру. Каждый пользователь может создавать/обновлять/удалять/просматривать свои собственные объекты статьи, но только просматривать статьи других без разрешения на их обновление / удаление.

из документов django разрешение уровня модели здесь не применяется. Если статье предоставлено разрешение на обновление уровня модели, то все пользователи могут обновлять статьи других пользователей.

Итак, я узнал о Джанго-хранителе. Однако, похоже, нет никакой надежды на эту самодостаточную модель CustomUser, поскольку она сильно зависит от Django auth.User модель!

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

обновление:

  1. мой случай-подкласс AbstractBaseUser вместо AbstractUser;
  2. это не для администратора, а только для моей серверной логики кода;
  3. я не использую API REST Django здесь, но если REST API является правильным, пожалуйста, приведите пример.
6
django permissions

3 ответов

разрешения объектного уровня не встроены в Django, даже при использовании стандартного auth.User - модели. Но основа в том, что Джанго PermissionsMixin определяет has_perm метод, который принимает экземпляр модели. Джанго ничего не делает по умолчанию, но вы можете.

The has_perm метод эффективно передает тяжелую работу на зарегистрированные бэкэнды аутентификации. Таким образом, вы можете создать пользовательский сервер аутентификации специально для выполнения вашего уровня объекта проверка разрешений. Его не нужно обрабатывать аутентификации. Это может быть так же просто, как один метод в базовом классе. Что-то вроде следующего (непроверенных) все, что вам нужно:

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

скажите Django использовать свой пользовательский бэкэнд с помощью AUTHENTICATION_BACKENDS настройка. В settings.py:

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

затем, в коде:

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

см https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#custom-users-and-permissions и https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#specifying-authentication-backends

12

на страница документация вы разместили, там же указано:

в основном, если мы подкласс AbstractUser или определить отношение " многие ко многим с двиг.Группа (и дать обратное название группы) мы должны быть штраф.

Так как это то, что вы делаете, вы должны установить AUTH_USER_MODEL как написано в Django documentention (см. билет и совершал код для Django 1.5 совместимость.)

0

в конечном итоге я использую логическое разрешение на каждый объект, чтобы он не изменял мою базу данных. Это django-правила, которые поддерживают мое представление на основе класса. Не забудьте переопределить redirect_field_name, иначе вы получите цикл перенаправления, если пользователи вошли в систему.

0