Django AdminSite/ModelAdmin для конечных пользователей?

Ответ 1

У нас есть система, которая работает только по вашему желанию.

Программа имеет базовый пользовательский логин, который является основным сайтом и использует ручные просмотры и шаблоны (как и должно быть)... Там есть Клиент часть, которая является основной страницей администратора с ограниченными правами доступа. И есть admin, кто я и люди, подобные мне.

Логика: администраторы - это люди, работающие в компании, у которых могут быть все права доступа (суперпользователи, как указано в sjango) или ограниченный доступ к приложениям, но могут видеть все связанные записи БД из тех, к которым у них есть доступ. Клиенты - это люди, которые продают нашу программу, у них ограниченный доступ к администратору, и они могут видеть только связанные с ними записи. пользователи - клиенты наших клиентов...

В этом случае разрешения django недостаточны, потому что наш клиент должен видеть, что запись принадлежит его учетной записи, а стандартный администратор может видеть все записи. Эти два могут достигать приложений в соответствии с их разрешениями. Суперпользователь может видеть и делать что угодно...

Для решения вместо usnig django site application (которое я никогда не использовал и не имел большой информации) мы создали модель, которая расширяет пользователя Django, у которого есть поле типа Роль - это роль пользователя является системным администратором, тогда он может видеть все (если суперпользователь, иначе он использует разрешения как обычно)... Если нет, он может достичь записей, относящихся к их веб-сайту (компания в вашей ситуации).

Итак, почти каждая таблица базы данных должна иметь внешний ключ, определяющий компанию-владельца соответствующей записи.

Таким образом, вы можете фильтровать записи, принадлежащие конкретной компании, если требуется...

В моих моделях у меня есть Kullanici, который наследует модель пользователя

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

Затем я пишу несколько методов, которые переопределяют методы администратора, like: ModelAdmin.save и modelAdmin.queryset, которые выполняют следующую проверку...

#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)

Итак, когда пользователь переходит к представлению списка приложений, он видит только связанные с ним сайты, другие записи не будут отображаться, или он получит ошибку permisson, если он попытается перейти к записи, принадлежат к другому сайту, Это все элементы управления django bassed, поэтому вы можете быть уверены, что они не достигнут записи ant, которую они не должны.

Вы должны переопределить все методы Admin, которые требуют фильтрации, принадлежат клиенту.

Для дальнейшего ограничения я использовал функцию для отображения/скрытия полей модели. В файле 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)

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

Handycaps: кэширование django admin может привести к тому, что случилось со мной один или два раза через 8 месяцев. Другая важная часть: вы не можете ограничить админ-фильтры, поэтому, если у вас есть фильтр, требующий ограниченного доступа, вы не можете фильтровать ключи фильтра. Вы можете отображать его со всеми параметрами или просто не использовать.

Если этот подход решает вашу проблему, я могу написать более подробную информацию...

UPDATE: Да, система разрешений проста и безопасна, если вы проверите исходный код разрешенного_захвата декоратора из последнего кода внешней линии...

Логика проста, у пользователя есть соответствующий разрешающий элемент, связанный с ним вид ececuted. В противном случае соответствующий вид или код вообще не выполняются. Таким образом, permissons обеспечивает достаточную защиту для администратора django. Управление разрешениями может использоваться как на уровне представления, так и на уровне шаблона.

Один момент, который должен быть осторожным, - это ручные представления, где небезопасный код может вызвать серьезные проблемы, но все это касается вашего кодирования, и это тот риск безопасности, с которым вам придется столкнуться на каждой платформе и на языке программирования...

Последний вопрос - это механизм фильтрации страниц django и admin. Поскольку почти все админ-фильтры используют GET для фильтрации данных и передают id на URL-адреса для отображения определенной записи. Seciruty часть django book показывает основную информацию о возможных проблемах безопасности и о том, как django обрабатывает их... С другой стороны, 22 Обновление безопасности в декабре 2010 г. показывает такую ​​важную уязвимость, которая требует достаточной информации о структуре модели.

Ответ 2

В admin нет ничего особенного. Он ведет себя точно так же, как и любое другое представление. Поэтому, если он использует разрешения для определения доступа (например, если вы устанавливаете пользователя .is_staff в True, но предоставляете им доступ только к определенным разрешениям), то он будет одинаково безопасен для любого вида, которое вы можете создать, которое использует разрешения для определить доступ.

В том же духе настройка, которую вы предоставляете ModelAdmin, приведет к реализации, которая будет одинаково безопасной, как и все, что вы можете написать.

Если вы пишете пользовательскую has_change_permission для своей модели, например:

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

Это сработает. Это не будет просто скрыть кнопку; он полностью блокирует редактирование этого объекта.

Люди, которые пишут django.contrib.admin, не пишут это с предположением, что любому, у кого есть is_staff = True, можно было бы доверять столько же, сколько суперпользователю, или было достаточно глупо, чтобы никогда не смотреть на исходный код веб-страницы, Хотя рекомендуется писать собственные взгляды, он по-прежнему является надежным интерфейсом.

См., например, этот раздел исходного кода, который вызывает исключение PermissionDenied, если вы пытаетесь получить доступ к change_view без разрешение на редактирование фактического объекта:

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...

Таким образом, даже если кто-то должен был создать правильный URL-адрес для редактирования данного объекта, если вы правильно выполнили has_change_permission, пользователю будет отказано в доступе.

Ответ 3

Если администратор - настроенный с помощью предоставленных крючков, при необходимости - отвечает вашим потребностям, то, конечно, нет причин не использовать его. Дело в том, что вы должны быть реалистичными в отношении того, что он предоставляет и чего он не предоставляет, и быть уверенным, что вы не начнете нуждаться в функциональности, которая возможна только вне администратора. Я был на той дороге, и это некрасиво.