Управлять правами на уровне объектов

[Hellpain]

Спасибо за статью.
1) А почему решили пробрасывать ссылки на проект в каждой зависимой модели, а не сделать общий механизм подключаемых прав через generic fk (да, я знаю что медленней)?
2)

Отдельное приложение нужно для того, чтобы иметь хорошо определенную последовательность инсталлированных приложений. Мы разместим приложение authorize в конце списка INSTALLED_APPS в файле settings.py, чтобы к моменту регистрации прав все модели точно были известны системе.

Для этого есть ready hook docs.djangoproject.com/en/3.0/ref/applications/#django.apps.AppConfig.ready

[nnseva]

1) Не совсем понимаю, как здесь работал бы Generic FK. Generic FK не то чтобы медленнее, он просто неудобный, поэтому я стараюсь пользоваться им как можно реже. Здесь ведь и Generic FK в принципе, не нужен, достаточно общего абстрактного предка, правда там механизм объявления related_name какой-то недоделанный. Можно было бы сделать предка неабстрактным, но практика показывает что вот такое решение как раз действительно медленнее: многие запросы в развитом приложении будут пересекать границы JOIN между предком и наследником. Поскольку это туториал, хотелось обойтись без всех этих сложностей, проще всего было сделать ссылку в каждом классе, который ее требовал.
2) Можно и так, несущественно. Фокус с `INSTALLED_APPS` уже отработан на практике, а с ready hook надо будет прикинуть, может быть даже сделать автоматическую подгрузку правил.

[glader]

Сориентируйте пожалуйста, в чем основные отличия от github.com/django-guardian/django-guardian?

[nnseva]

Django-Guardian ориентируется на специализированную модель объекта прав, явным образом связывающую с помощью Generic PK пользователя с каждым объектом, для которого нужно установить права доступа.

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

Например, в рассмотренном примере, в случае Django-Guardian, чтобы установить, что пользователь 'test' имеет право изменять объект Vehicle '1234' принадлежащий данному проекту, нужно будет создать объект UserObjectPermission, связывающий 'test' с 1234'. В то же время для Django-Access с определенными в примере правилами доступа, сам факт того, что 'test' и '1234' принадлежат одному и тому же проекту, уже достаточен для того, чтобы определить порядок доступа.

Таким образом, функциональные связи, уже существующие в проекте, становятся достаточны (или почти достаточны) для того, чтобы установить порядок доступа, в то время как Django-Guardian требует создания явной связки между пользователем и объектом модели в специальной таблице.

В этом смысле, Django-Access больше похож на пакет Django Permissions, но у последнего есть другие проблемы, которые решены в Django-Access.