Уведомления

Группа в Telegram: присоединиться

#1 Авг. 10, 2011 08:06:45

Cykooz
От:
Зарегистрирован: 2010-10-07
Сообщения: 46
Репутация: +  0  -
Профиль   Отправить e-mail  

Как запретить доступ к виду для не авторизованных пользователей?

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



Офлайн

#2 Авг. 10, 2011 09:46:26

Sleepwalker
От:
Зарегистрирован: 2008-07-18
Сообщения: 68
Репутация: +  0  -
Профиль   Отправить e-mail  

Как запретить доступ к виду для не авторизованных пользователей?

На счет специального 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
Можно конечно в коде самого вида генерировать исключение для ананимусов, но это как самый последний вариант.
Да это немного неправильно, но если и делать, то как по мне лучше в траверсере все это делать.



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

Офлайн

#3 Авг. 10, 2011 23:20:41

astoon
От:
Зарегистрирован: 2007-04-09
Сообщения: 335
Репутация: +  2  -
Профиль   Отправить e-mail  

Как запретить доступ к виду для не авторизованных пользователей?

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

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



Офлайн

#4 Авг. 11, 2011 07:43:29

Cykooz
От:
Зарегистрирован: 2010-10-07
Сообщения: 46
Репутация: +  0  -
Профиль   Отправить e-mail  

Как запретить доступ к виду для не авторизованных пользователей?

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



Офлайн

#5 Авг. 30, 2011 12:42:03

Cykooz
От:
Зарегистрирован: 2010-10-07
Сообщения: 46
Репутация: +  0  -
Профиль   Отправить e-mail  

Как запретить доступ к виду для не авторизованных пользователей?

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



Офлайн

#6 Дек. 15, 2014 21:02:38

sajjad123
Зарегистрирован: 2014-12-15
Сообщения: 1
Репутация: +  0  -
Профиль   Отправить e-mail  

Как запретить доступ к виду для не авторизованных пользователей?

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



Cut down your exam stress by using our latest 700-501 - latest dumps and high quality SY0-401 - pass4sure - braindumps.com gmat and lynn We provide updated www.sterling.edu

Офлайн

Board footer

Модераторировать

Powered by DjangoBB

Lo-Fi Version