Не уверен, что вы уже читали об этом, но у пирамиды действительно хорошая система разрешений. Авторизация через ACL.
Как с этим справиться, это действительно зависит только от вас... У вас может быть таблица ACL
(object_id, разрешить/запретить, кто? (группа, идентификатор пользователя), разрешение, порядок)
- object_id — это уникальный идентификатор записи в вашей базе данных.
- разрешить/запретить - это то, что должен делать этот ACE... разрешить или запретить доступ
- кто? это либо группа, либо имя пользователя, либо что угодно, например, system.everyone — это все
- разрешение — это параметр разрешения в view_config.
- порядок - это одна важная вещь порядок имеет значение
Например
__acl__ = [
(Deny, Everyone, 'view'),
(Allow, 'group:admin', 'view')
]
Этот образец всегда будет запрещать просмотр даже для администратора... Как только пирамида найдет что-то, что говорит вам, можете ли вы видеть или не видеть запись, она автоматически прекращает поиск.
__acl__ = [
(Allow, 'group:admin', 'view'),
(Deny, Everyone, 'view')
]
Это позволит просматривать для каждого администратора, но не для всех остальных. Вот почему вы должны помнить порядок своих ACE.
На самом деле самое интересное здесь. Это все хорошо. У вас есть acl, сопоставленный с записью в ваших данных. Когда вы загружаете, например, страницу... Вам нужно будет загрузить acl и установить их в свой объект.
myobject.__acl__ = load_acls(myobject)
Если у вас есть дерево данных. Можно даже не ставить acls.
Например, у вас есть сайт, который выглядит так
root
\--pages with acl
+---- page1 without acl
\---- page2 with acl
Когда вы получите доступ к странице 1, он проверит acl, если не сможет его найти, он проверит parent, если parent имеет acl , он будет проверять разрешение для него, если нет, он будет проверять его родителя, пока вы не достигнете root. Если он не может найти разрешение, я не уверен, что произойдет. Я думаю, это либо даст вам запрещенную ошибку, либо предикатную ошибку. Что он не может найти правильный вид.
Тем не менее, для того, чтобы сделать эту работу, вы должны сделать объект осведомленным о местоположении, который знает своих родителей.
Но зачем тебе все это?
Вы можете иметь acl для любого объекта и иметь очень тонкий контроль над тем, кто может просматривать или не просматривать каждый объект в вашей базе данных. Вы также можете поместить acl непосредственно в объект класса без базы данных.
пока ваш acl находится в пирамиде атрибутов acl, вы сможете что-то с ним сделать. Не так важно, как вы это получили.
Проверь это
http://pyramid.readthedocs.org/en/1.3-branch/tutorials/wiki/authorization.html
person
Loïc Faure-Lacroix
schedule
20.04.2012
GRANT/REVOKE, которая используется для разрешения доступа (на разных уровнях) к таблицам/схемам в базе данных. Некоторые из них даже имеют концепцию групп пользователей, что означает, что вы можете выполнять команду для всей группы. Таким образом, вы можете попытаться сделать что-то на уровне приложения, которое уже присутствует на уровне базы данных (что было бы гораздо более безопасным). - person Clockwork-Muse schedule 17.04.2012GRANTпредназначен для пользователей базы данных, да. Но если вы написали свое приложение для проверки разрешений (в зависимости от того, кто/что вошел в приложение), вы также можете войти в них как конкретный пользователь базы данных (обычно вы можете указать их в строке подключения). Это поможет с аудитом, а также с контролем доступа. - person Clockwork-Muse schedule 18.04.2012