On Fri, Dec 02, 2005 at 09:38:56AM +0000, Chris Withers wrote:
> Dario Lopez-K?sten wrote:
> >Most, if not all examples, out there assume that the external 
> >packages/modules/classes can freely be converted to Zope-classes.
> No so, all you have to do is provide security assertions for them. I 
> usually do this is a dummy product's __init__.py.
> See the examples in PythonScripts standard.py...

Those are mostly to do with declaring callables (i.e. functions)
importable, by using ModuleSecurityInfo().declarePublic('foo').
Very useful, but it doesn't show how to allow scripts to
use already instantiated objects passed to a Script from
some product code.

One way is to do the following in a method of
your trusted (product) code:

1) create a derived or wrapper class that inherits from
Acquisition.Implicit or Acquisition.Explicit.
This can either inherit from your existing class,
or wrap it, as you prefer.

2) in the wrapper class, use ClassSecurityInfo() to 
declare the methods you need public or permission-protected,
or use allowAny().

3) initializeClass(myWrapper)

4) instantiate one of these and give it a security context,
e.g. myWrapperInstance = myWrapper(existing_object).__of__(self) 

5) return the wrapper

You know, some days I wonder why it is that Zope is the
only framework around that needs to distinguish between 
"trusted" and "untrusted" code. Nobody else seems to be
looking at us with envy in this regard.
Historically I know it was because there was the idea that
not-fully-trustworthy people might be able to join your site
and then add DTML to it, and you don't want such people
allowed to execute arbitrary code ... like the old zope.org
site.  But does anybody anywhere actually run a site like that
nowadays? It's kind of a bizarre idea.


Paul Winkler
Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to