- В документации Zope довольно ясно сказано, что не нужно возвращать из ВнешнихМетодов обьекты классов. Возвращать нужно, в худшем случае, коллекции или итерируемые обьекты, тогда их можно будет использовать в DTML, ZPT и прочих обертках/шаблонах.
- Довольно туманно сказано, зачем было наложено такое ограничение. Нет, в целом, конечно, понятно — безопасность и такое-прочее.
- И практически ничего не сказано, как это ограничение обойти, при необходимости. Но если поискать, то тайна оказывается вовсе не тайной, а одним из решений дизайна модели расширяемости.
-
- Вот, собственно, рецепт обхода ограничения:
-
- zope.org/Documentation/How-To/ProductAuthorUpdateGuide
-
- В модуле ВнешнегоМетода у вас класс, обьект которого вы хотите возвращать в DTML, к примеру. Для последующего юзания. Тогда после определения имени класса пишите волшебную строку «__allow_access_to_unprotected_subobjects__=1» и начинайте думать о том, как закрыть доступ хакерам к атрибутам данного класса и всех его базовых классов.
- Все или ничего, вот какой вопрос стоял перед разработчиками Zope. Если открывать доступ к атрибутам классов, то ко всем. Поэтому они предпочли по умолчанию закрыть доступ. Я бы тоже так сделал на их месте.
-
For instance, lets say you have an External Method that returns instances of a Thing
class that you have created. You want to be able to call the External Method from DTML and iterate over the 'Thing's returned to make a report. Your Thing
class is not a Zope class of any kind, so it doesn't know about permissions or anything else about the Zope security model. To be able to access the methods and attributes of your 'Thing's from DTML you will need to add the special declaration to the Thing
class for the security model to allow you access to those unprotected methods:
class Thing:
# This tells the security policy that its ok to use attributes
# of this object even though they aren't explicitly protected
__allow_access_to_unprotected_subobjects__=1
def name(self):
return self._name
Product authors should be very careful about using this special declaration as all subobjects not explicitly protected will now be accessible. Note when you add this security assertion that all unprotected attributes in the base classes of the object will be affected as well.
Комментариев нет:
Отправить комментарий