Будет ли Django хорошим выбором для веб-приложения, основанного на разрешениях?

Я изучаю детали Django уже около недели и люблю то, что вижу. Однако я столкнулся с некоторой отрицательностью в отношении мелкозернистого контроля разрешений на интерфейс CRUD.

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

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

Будет ли Django создавать пользовательские разрешения/правила и легко интегрировать его в интерфейс администратора CRUD?

Update One: я хочу использовать приложение admin для минимизации повторения генерирующих интерфейсов CRUD, поэтому да, я считаю, что он должен иметь.

Обновить два:

Я хочу описать разрешения, необходимые для этого проекта.

Клиент может принадлежать одному или нескольким "магазинам". Сотрудники, работающие полный рабочий день, должны иметь возможность редактировать клиентов в своем магазине (даже если они принадлежат другому магазину). Однако они не должны видеть/редактировать клиентов в другом магазине. Повреждения должны иметь возможность просматривать только клиенты, основываясь на том, в каком хранилище они заносятся в список (или если случайный пользователь зарегистрирован как пользователь магазина).

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

Старшее руководство должно иметь возможность редактировать ВСЕ сотрудников и предоставлять разрешения под себя.

После чтения документации django в нем говорится, что вы не можете (автоматически) устанавливать разрешения для подмножества группы. Только вся группа. Достаточно ли достаточно макета для ваших собственных прав для этой цели?

Ответы

Ответ 1

Если я правильно прочитаю ваши обновленные требования, я не думаю, что достаточная система авторизации Django. Похоже, вам нужна полноценная система ACL.

Этот вопрос появился несколько раз. Попробуйте googling на django + acl.

Случайные выборки...

Был проект Summer of Code пару лет назад, но я не уверен, где они добрались. См. http://code.djangoproject.com/wiki/GenericAuthorization

В djngoproject.org есть свежий билет, который может быть интересным:

На dumpz.org есть несколько интересных фрагментов кода:

... но есть нулевые документы.

Удачи!

Ответ 2

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

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

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

И если этого недостаточно для вас, надстройка профиля дает вам еще больше возможностей для определения "User" и их возможностей, разрешений, ролей, обязанностей и т.д.

И если этого недостаточно для вас, вы можете определить свои собственные схемы аутентификации.

Важно не пытаться определить группы, являющиеся фактическими подмножествами пользователей, а не случайно определенные названия или роли. Вам никогда не нужно "устанавливать разрешения для подмножества группы". Вы должны иметь меньшие группы. Группы, определенные вокруг подмножеств людей.

Разрешения по умолчанию Django связаны с доступом к модели, а не с доступом к строке в модели. С другой стороны, ваша проблема связана с подмножествами строк в нескольких моделях: Client, Store, Employee, Manager.

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

Если вы не можете сделать это с помощью системы разрешений Django, вы должны пересмотреть свои варианты использования. Серьезно.

[Интерфейс Django-REST, однако, является еще одним зверьком и требует некоторой осторожности и кормления.]

Ответ 3

Объекты ModelAdmin имеют методы has_add_permission, has_change_permission, has_delete_permission и queryset, которые могут использоваться для принудительного разрешения разрешений то, что может видеть и модифицировать зарегистрированный пользователь, - вы можете создать подкласс, который использует их для обеспечения всех разрешений, которые вы хотите реализовать, и зарегистрировать все ваши модели с помощью приложения admin, используя ваш подкласс.

Однако все зависит от того, как именно будет работать ваша система разрешений - каковы точные требования, которые выпадают из ваших мелких разрешений? Чем больше вы уходите от того, что было разработано для приложения admin, тем больше будет его работы, но есть много крючков, которые вы можете использовать для реализации своих пользовательских требований. Здесь сообщение в блоге от Luke Plant, в котором приводятся примеры некоторой тонкой настройки, которую вы можете сделать, не зарываясь слишком глубоко.

Нужно ли это основываться на приложении admin? Общие представления и ModelForms может позаботиться о много утомительных бит, участвующих в реализации CRUD, поэтому быть осторожным о том, чтобы слишком повредить настройку admin - это почти традиция Django для начала, повесив приложение admin и что он может и не может сделать, изначально думая, что вам больше не придется писать код;)

Ответ 4

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

Ответ 5

Возможно, вам также захочется взглянуть на пакетную правку monkeypatch: http://code.google.com/p/django-granular-permissions/

Он добавляет разрешения на уровне строк в систему разрешения django.