Будет ли Django хорошим выбором для веб-приложения на основе разрешений?
Я изучаю детали Django около недели, и мне нравится то, что я вижу. Однако я наткнулся на некоторые негативные моменты в отношении детального контроля разрешений на интерфейс CRUD.
Я пишу веб-приложение для управления клиентами в интрасети. В организации около 6 уровней, и мне нужно ограничить доступ к группам клиентов на основе уровней. Постоянно расширяется. У меня есть довольно хорошее представление о том, как я собираюсь это сделать, но я не уверен, смогу ли я хорошо интегрировать это в предварительно созданный интерфейс администратора.
Я абсолютно не занимался разработкой Django, иначе я бы, вероятно, лучше понял, сработает это или нет. Я, вероятно, не буду использовать Django, если сгенерированный интерфейс администратора будет бесполезен для этого проекта, но, как я уже сказал, существует большая зависимость от детализированных настраиваемых разрешений.
Позволит ли Django создавать настраиваемые разрешения / правила и легко интегрировать их в интерфейс администратора CRUD?
Обновление первое: я хочу использовать приложение администратора, чтобы свести к минимуму повторение создания интерфейсов CRUD, поэтому да, я считаю это обязательным.
Обновление два:
Я хочу описать разрешения, необходимые для этого проекта.
Клиент может принадлежать к одному или нескольким «магазинам». Сотрудники, занятые полный рабочий день, должны иметь возможность редактировать клиентов только в своем магазине (даже если они принадлежат другому магазину). Однако они не должны видеть / редактировать клиентов в другом магазине. Обычные пользователи должны иметь возможность просматривать клиентов только в зависимости от того, в каком магазине они находятся (или если случайный пользователь вошел в систему как пользователь магазина, что более вероятно).
Руководству над ними нужно иметь возможность видеть всех сотрудников магазинов, которыми они управляют, не более того.
Старшее руководство должно иметь возможность редактировать ВСЕХ сотрудников и предоставлять разрешения ниже себя.
После прочтения документации django в нем говорится, что вы не можете (автоматически) устанавливать разрешения для подмножества группы. Только вся группа. Достаточно ли просто для этой цели создать макет собственных разрешений?
Ответы 6
Объекты ModelAdmin имеют методы has_add_permission, has_change_permission, has_delete_permission и queryset, которые можно использовать для обеспечения разрешений на то, что зарегистрированный пользователь может видеть и изменять - вы можете создать подкласс, который будет использовать их для обеспечения любых разрешений, которые вы хотите реализовать, и зарегистрировать все свои модели с приложением admin, используя ваш подкласс.
Однако все зависит от того, как именно будет работать ваша система разрешений - каковы точные требования, которые выпадают из ваших детализированных разрешений? Чем больше вы отдаляетесь от того, для чего было разработано приложение admin, тем больше работы потребуется, но в нем есть много ловушек, которые вы можете использовать для реализации своих индивидуальных требований. Вот сообщение в блоге Люка Планта, который дает примеры некоторых тонких настроек, которые вы можете сделать, не копая слишком глубоко.
Обязательно ли он должен быть основан на приложении admin? Общие представления и МодельФормы могут позаботиться о многих утомительных битах, связанных с реализацией CRUD, поэтому будьте осторожны слишком зацикливается на настройке admin - это почти традиция Django - начинать с того, что зацикливается на приложении admin и его возможностях не делаю, изначально думая, что вам больше никогда не придется писать код;)
Система разрешений Django полностью рулит. Каждая модель имеет набор разрешений по умолчанию. Вы также можете добавить новые разрешения к своим моделям.
У каждого пользователя есть набор разрешений, а также членство в группах. Отдельные пользователи могут иметь индивидуальные разрешения. И они наследуют разрешения от своего членства в группе.
Ваши функции просмотра (и шаблоны) могут легко проверить наличие и отсутствие этих разрешений на любом уровне детализации, который вам нужен.
А если вам этого недостаточно, надстройка Profile дает вам еще больше возможностей для определения «Пользователя» и его возможностей, разрешений, ролей, обязанностей и т. д.
А если вам этого недостаточно, вы можете определить свои собственные схемы аутентификации.
Важно не пытаться определить группы, которые являются фактическими подмножествами пользователей, а не определенными заголовками или ролями случайно. Вам никогда не нужно «устанавливать разрешения для подмножества группы». Вам нужно иметь небольшие группы. Группы, определенные вокруг подмножеств людей.
Разрешения Django по умолчанию связаны с доступом к модели, а не с доступом к строкам внутри модели. С другой стороны, ваша проблема связана с подмножествами строк в нескольких моделях: Клиент, Магазин, Сотрудник, Менеджер.
Вам понадобится базовый набор FK среди этих элементов и несколько фильтров для подмножества строк. У вас могут возникнуть проблемы с этим со страницами администратора по умолчанию. Для использования специализированных фильтров вам может потребоваться собственная версия администратора.
Если вы не можете сделать это с помощью системы разрешений Django, вам следует переосмыслить варианты использования. Серьезно.
[Интерфейс Django-REST, однако, совершенно другой зверь и требует некоторого ухода и кормления.]
Если я правильно прочитал ваши обновленные требования, я не думаю, что существующей системы аутентификации Django будет достаточно. Похоже, вам нужна полноценная система ACL.
Эта тема поднималась несколько раз. Попробуйте погуглить на django + acl.
Случайные выборки ...
Пару лет назад был проект Summer of Code, но я не уверен, к чему они пришли. См. http://code.djangoproject.com/wiki/GenericAuthorization
На djngoproject.org есть новый билет, который может быть интересен:
На dumpz.org есть несколько интересных фрагментов кода:
- http://dumpz.org/274/ models.py
- http://dumpz.org/273/ signal.py
... но нет документов.
Удачи!
Вы также можете взглянуть на monkeypatch гранулярных разрешений: http://code.google.com/p/django-granular-permissions/
Он добавляет разрешения на уровне строк в систему разрешений django.
Я только что нашел http://bitbucket.org/jezdez/django-authority/, это выглядит многообещающе.
В django 1.2 есть поддержка разрешений на уровне строк, обработка которых с помощью джанго-хранитель очень интуитивно понятна.
Большая часть работы уже проделана с помощью приложения для администрирования - оттуда и будет зависеть большая продуктивность. Мне просто нужен способ установить, кто к чему имеет доступ. См. Мое обновление выше для примера.