Python-сообщество

Необходимо в приложении для BlueBream запретить доступ к виду только для не авторизованных пользователей. Может есть какой то специальный permission для этого, или надо будет создавать свой собственный и раздать его всем ролям кроме zope.Anonymous? Можно конечно в коде самого вида генерировать исключение для ананимусов, но это как самый последний вариант.

На счет специального permission - не припомню такого. Лучше всего написать свой:

    <premission 
        id="somesite.AllowView"
        title="Allow view"
        />

    <page
        name="someview"
        for="*"
        class="some.View"
        require="somesite.AllowView"
        />

from zope.app.securitypolicy.interfaces import IPrincipalPermissionManager

perm_manager = IPrincipalPermissionManager(user) # user - обьект созданного пользователя
perm_manager.grantPermissionToPrincipal('somesite.AllowView', principal_id) # Точно не помню, стоит посмотреть в док. какие параметры у этого метода

Cykooz
Можно конечно в коде самого вида генерировать исключение для ананимусов, но это как самый последний вариант.

Отредактировано (Авг. 10, 2011 09:47:38)

Попробую обозначить общие стратегии.

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, опять же.

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

Оказалось, что класс zope.site.folder.Folder по умолчанию имеет пермишен zope.View для интерфейса zope.container.interfaces.IReadContainer. Это привело к тому, что ананимус без пермишена zope.View не может получить ни один объект в корне ZODB. Придётся переопределить права доступа для zope.site.folder.Folder.
Надеюсь больше не будет подобных моментов.

Если кроме самого ZTK имеет место использование еще какого-либо ZTK-основанного фреймворка (plone, grok и проч.), в нем могут встречаться свои общепринятые права доступа. Они обычно распостраняются в третьесторонних пакетах, сделанных под этот фреймворк, поэтому нужно стараться использовать их.