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

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

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

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

Позволит ли Django создавать собственные разрешения/правила и беспрепятственно интегрировать их в интерфейс администратора CRUD?

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

Обновление два:

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

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

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

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

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


person Josh Smeaton    schedule 23.10.2008    source источник


Ответы (6)


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

Эта тема поднималась не раз. Попробуйте погуглить django+acl.

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

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

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

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

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

Удачи!

person Peter Rowell    schedule 25.10.2008

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

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

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

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

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


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

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

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


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

[Однако интерфейс Django-REST — это совершенно другой зверь, требующий некоторого ухода и подпитки.]

person S.Lott    schedule 24.10.2008

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

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

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

person Jonny Buchanan    schedule 24.10.2008
comment
Большая часть работы уже проделана с приложением администратора — вот откуда будет большая производительность. Мне просто нужен способ обеспечить, кто имеет доступ к чему. См. мое обновление выше для примера. - person Josh Smeaton; 24.10.2008

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

person HdN8    schedule 10.08.2011

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

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

person bruno desthuilliers    schedule 27.11.2008

Я только что нашел http://bitbucket.org/jezdez/django-authority/. , выглядит многообещающе.

person Community    schedule 27.08.2009