Cykooz
Авг. 10, 2011 08:06:45
Необходимо в приложении для BlueBream запретить доступ к виду только для не авторизованных пользователей. Может есть какой то специальный permission для этого, или надо будет создавать свой собственный и раздать его всем ролям кроме zope.Anonymous? Можно конечно в коде самого вида генерировать исключение для ананимусов, но это как самый последний вариант.
Sleepwalker
Авг. 10, 2011 09:46:26
На счет специального permission - не припомню такого. Лучше всего написать свой:
<premission
id="somesite.AllowView"
title="Allow view"
/>
В виде соответсвенно написать require:
<page
name="someview"
for="*"
class="some.View"
require="somesite.AllowView"
/>
Теперь дать это право пользователю: либо повесить handler на создание пользователя, либо давать права в виде для регистрации:
from zope.app.securitypolicy.interfaces import IPrincipalPermissionManager
perm_manager = IPrincipalPermissionManager(user) # user - обьект созданного пользователя
perm_manager.grantPermissionToPrincipal('somesite.AllowView', principal_id) # Точно не помню, стоит посмотреть в док. какие параметры у этого метода
Cykooz
Можно конечно в коде самого вида генерировать исключение для ананимусов, но это как самый последний вариант.
Да это немного неправильно, но если и делать, то как по мне лучше в траверсере все это делать.
astoon
Авг. 10, 2011 23:20:41
Попробую обозначить общие стратегии.
1. По мере возможности нужно стараться использовать права доступа, применяемые в ZTK. Это права доступа с пространством имен “zope”, такие как zope.View, zope.ManageContent, zope.ManageServices. Можно назвать такие права общепринятыми. Их преимущество в том, что третьесторонние компоненты обычно используют их. Учитывая тот факт, что изначальной мотивацией архитектуры zope3 была возможность легко и красиво подключать третьесторонние пакеты, этот аргумент представляется достаточно весомым.
2. Если кроме самого ZTK имеет место использование еще какого-либо ZTK-основанного фреймворка (plone, grok и проч.), в нем могут встречаться свои общепринятые права доступа. Они обычно распостраняются в третьесторонних пакетах, сделанных под этот фреймворк, поэтому нужно стараться использовать их.
3. Если взглянуть на разработку проекта во времени, то эмпирически оправданным правилом будет использование общепринятых прав доступа изначально и так долго, насколько это возможно. И только когда совсем “прижмет”, вводить новые права. Благо вся эта работа сводится большей частью к написанию сугубо декларативных zcml правил. Иначе, если проект развивается достаточно креативно, разработчики часто будут приходить к выводу, что совсем не обязательно было “наворачивать” такую систему прав. Когда она уже “навороченная”, то менять ее будет сложнее.
4. В стандартном шаблоне BlueBream задекларировано правило по умолчанию grant permisison=“zope.View” role=“zope.Anonymous”. Но это отнюдь не означет, что данное правило должно оставаться в проекте. Это - не более чем удобство для ранних стадий разработки. Если имеет место достаточно дифференцированная политика безопасности, то это правило должно быть удалено.
5. Первая стратегия подразумевает удаление указанного выше правила, и grant прав на роли или на пользователей в пределах локальных Security Map. В том числе и grant'ы на роль zope.Anonymous тогда, когда это необходимо. Кроме локальных настроек могут быть и глобальные - на уровне классов (zcml объявление class). Данная стратегия хороша тем, что декларации безопасности на уровне видов остаются вполне стандартными - zope.View для показа объекта, zope.ManageContent - для его изменения.
6. Вторая стратегия в целом сходна с предыдущей, за исключением того, что grant на роль zope.Anonymous вообще не делается никогда. Вместо этого на уровне декларации видов используется permission=“zope.Public”. Он как раз для этого и предназначен.
7. Третья стратегия - это введение собственных прав на ранних стадиях разработки проекта. Чем меньше их - тем лучше. Данная стратегия чаще всего оправдана в том случае, когда поведение стандартного Security Policy, подразумевающее распостранение прав вглубь иерархии объектов ZODB в каком-то месте не помогает, а наоборот мешает. Например, владелец некоего контейнера будет становиться по умолчанию владельцем и его вложенных объектов, а нам это совсем не нужно, так как у них есть свои владельцы. Это просто решается введением специализированных прав.
8. Четвертая стратегия подразумевает введение собственных локальных адаптеров безопасности. Т.е. адаптеров от интерфейсов своих объектов, к таким интерфейсам, как IPrincipalRoleMap. Этот вариант “крут” настолько же, как и введение собственного Security Policy, но абсолютно не трудоемок. Даже наоборот, его можно считать вариантом для ленивых. Поэтому я такой вариант иногда использую. В методах адаптера можно понаписать черти чего, и все это будет работать. Нельзя назвать его достаточно красивым, и чаще всего ваши адаптеры будут иметь достаточно примитивное поведение. Но поведение точно такое какое требуется Вам. Это вариант я считаю также приемлемым, так как он определяет поведение, связанное с безопасностью, в отдельном адаптере. И все это отключается-включается одной строкой в zcml, опять же.
Cykooz
Авг. 11, 2011 07:43:29
Всем спасибо за советы. Пожалуй вариант с отключением для ананимуса пермишена zope.View мне нравится больше всего.
Cykooz
Авг. 30, 2011 12:42:03
Оказалось, что класс zope.site.folder.Folder по умолчанию имеет пермишен zope.View для интерфейса zope.container.interfaces.IReadContainer. Это привело к тому, что ананимус без пермишена zope.View не может получить ни один объект в корне ZODB. Придётся переопределить права доступа для zope.site.folder.Folder.
Надеюсь больше не будет подобных моментов.
sajjad123
Дек. 15, 2014 21:02:38
Если кроме самого ZTK имеет место использование еще какого-либо ZTK-основанного фреймворка (plone, grok и проч.), в нем могут встречаться свои общепринятые права доступа. Они обычно распостраняются в третьесторонних пакетах, сделанных под этот фреймворк, поэтому нужно стараться использовать их.