PythonScripts are for *scripting* not for implementing complex logic and for programming tasks that require classes. PythonScripts don't provide full Python functionality that why were are talking of *Restriced Python*. Consider writing your functionality as Python product.

And sometimes a supporting class or function makes such code all the simpler. Knowing how to enable Python code to be imported into scripts is an essential tool. -- Martijn Pieters

Andreas Jung wrote:

Sure you can but you shouldn't..you start with one class and at the end you have an application with tons of such code....you can program that way but you shouldn't :-)

I will print and read the Developer Book... ;) Thanks for all replies. Fernando Lujan

Dario Lopez-Kästen wrote:

Andreas Jung wrote:

...

--On 1. Dezember 2005 13:46:55 -0200 Fernando Lujan <fernando.lujan@terra.com.br> wrote:

...

There's a way to use a Python class inside zope?

For instance, if I create the class:

class MyClass: "A simple example class" i = 12345 def f(self): return 'hello world'

Can I invoke the following code inside a Python Script?

x = MyClass() x.f()

PythonScripts are for *scripting* not for implementing complex logic and for programming tasks that require classes. PythonScripts don't provide full Python functionality that why were are talking of *Restriced Python*. Consider writing your functionality as Python product.

all moral lessons aside, there are several use cases where access to *objects*, passed to zope2 from external packages and modules, is desirable.

Most, if not all examples, out there assume that the external packages/modules/classes can freely be converted to Zope-classes.

Now, assuming that I have not missed something fundamental, the problem the way I see it, is that when my Product recieves an object from the non-zope code, the object does not know anything about Zope, it is just a happy Python-object.

But in order to even display it in a zpt I must transmogrify it into a special zope-object, and *that* is not so easy as I have discovered.

In my case I am not so interested in importing the moduels or classes into a Script(Python) - I have allready passed the objects in question thtough my product, but still I get some "Zope Does Not Allow That" error.

So far I have not had any success with anything else than writing special methods in my Classes that converts the objects to dictionaries before passing them to the zpt or Script(Python) in question.

But that feels like a very awkward way of doing things, and it makeas it *very* difficult for Zope to be a nice player with non-zope objects.

My 2 €-cents worth.

/dario

You need to call InitializeClass on your object, and that's it. cf http://www.upfrontsystems.co.za/courses/zope/ch04.html under "Zopifying our Python classes" /JM

Paul Winkler wrote:

On Thu, Dec 01, 2005 at 09:04:11PM +0100, Jean-Marc Orliaguet wrote:

...

You need to call InitializeClass on your object, and that's it.

cf http://www.upfrontsystems.co.za/courses/zope/ch04.html

under "Zopifying our Python classes"

initializeClass() only helps if the class you feed it inherits from Acquisition.Implicit or Acquisition.Explicit, and has some security declarations in it.

for protected methods, but what if your methods are public? http://www.zope.org/Wikis/DevSite/Projects/DeclarativeSecurity/ZopeSecurityF... ------------------------ - It is important to note what can and cannot be protected using the |SecurityInfo| interface. First, the security policy relies on /Acquisition/ to aggregate access control information, so any class that needs to work in the security policy must have either |Acquisition.Implicit| or |Acquisition.Explicit| in its base class hierarchy. - if the object has a security assertion that it is /public/ then access will be granted ------------------------ does zope2 do an access control based on acquisition for public methods, that would be a waste of resources since the answer is always "yes, granted" ? /JM

Paul Winkler wrote:

On Fri, Dec 02, 2005 at 04:12:01PM +0100, Jean-Marc Orliaguet wrote:

...

does zope2 do an access control based on acquisition for public methods, that would be a waste of resources since the answer is always "yes, granted" ?

Well, the thing is, the declaration that makes the method public *has no effect* unless your class participates in acquisition.

That's not true. The objects of this class will be perfectly accessible to a restricted user: from AccessControl import ClassSecurityInfo class MyStuff(object): security = ClassSecurityInfo() security.declareObjectPublic() security.setDefaultAccess('allow') def foo(self): return 'bar' InitializeClass(MyStuff) Which also can be written more shorly an less invasively: class MyStuff(object): def foo(self): return 'bar' from AccessControl import allow_class allow_class(MyStuff) allow_class does the same thing as declareObjectPublic + setDefaultAccess('allow') For instance you could have in you this same code: from AccessControl import ModuleSecurityInfo ModuleSecurityInfo('Products.ThisProduct.ThisFile' ).declarePublic('getStuff') def getStuff(): return MyStuff() And in restricted code you can then do: from Products.ThisProduct.ThisFile import getStuff ob = getStuff() v = ob.foo()

Oh, and the instance needs to be given an acquisition context, too. e.g. foo = foo.__of__.some_parent

It's only if you want to protect a method with a specific permission that's not public or private that you'll have to provide acquisition context so that Zope can find out what roles have this permission and match them against the current user's roles: class MyStuff(Acquisition.Implicit): security = ClassSecurityInfo() security.declareObjectPublic() security.setDefaultAccess('allow') def foo(self): return 'bar' security.declareProtected('View') def viewit(self): return 'yo mama' InitializeClass(MyStuff) ... def getStuff(context): return MyStuff().__of__(context) Then in restricted code you'll be able to do: ... ob = getStuff(context) v = ob.viewit() Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com

Florent Guillaume wrote:

Paul Winkler wrote:

...

On Fri, Dec 02, 2005 at 04:12:01PM +0100, Jean-Marc Orliaguet wrote:

...

does zope2 do an access control based on acquisition for public methods, that would be a waste of resources since the answer is always "yes, granted" ?

Well, the thing is, the declaration that makes the method public *has no effect* unless your class participates in acquisition.

That's not true. The objects of this class will be perfectly accessible to a restricted user:

from AccessControl import ClassSecurityInfo class MyStuff(object): security = ClassSecurityInfo() security.declareObjectPublic() security.setDefaultAccess('allow') def foo(self): return 'bar' InitializeClass(MyStuff)

In Zope 2.7.8 I get a segmentation fault when I try to do the above; I also have the following code that manages this for any class (to avoid having to do that for every single class): def _ZopifyClass(a_class): a_class.security = ClassSecurityInfo() a_class.security.declareObjectPublic() # Segmentation fault security.setDefaultAccess('allow') InitializeClass(a_class) I cannot swithc to Zope 2.8 because my code runs in PLone 2.05 and it does not work with Zope 2.8. The segmentation fault occurs in the declareObjectPublic() statement. Is there a fix for the Zope 2.7 to this problem? Thanks. /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley

Jean-Marc Orliaguet wrote:

is it a typo, or did you mean:

a_class.security.setDefaultAccess('allow')

it is a type and I do mean a_class.security.setDefaultAccess('allow'). /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley

Jean-Marc Orliaguet wrote:

that's because it does not seem to work with new-style python classes in zope2.7

it works with:

class MyStuff:

instead of:

class MyStuff(object):

This is what you would have got:

File "/opt/Zope-2.7/lib/python/AccessControl/SecurityInfo.py", line 165, in apply dict['%s__roles__' % name] = access TypeError: object does not support item assignment

if you'd run it without the extra call.

now, the question is if it's worth the extra effort.

aha!; thanks for the explanation. Well, as you know, we have not officially gotten so far with implementing new style class features on our base classes (that is, unless you have checked in som extra code lately that relies on NSC) Considering the time frame we are living with - yes, not using NSC is definitely the way to go for now, until I have time to upgrade to Plone 2.1.1 and Zope 2.8 or 2.9. Thanks! /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley

According to Dario Lopez-Kästen:

But in order to even display it in a zpt I must transmogrify it into a special zope-object, and *that* is not so easy as I have discovered.

In my case I am not so interested in importing the moduels or classes into a Script(Python) - I have allready passed the objects in question thtough my product, but still I get some "Zope Does Not Allow That" error.

You could add __allow_access_to_unprotected_subobjects__ = 1 to your class. Then all attributes and methods of its instances should be accessible from Zope. However, this can be a security problem, so be careful... \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/9207 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria

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... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

On Dec 2, 2005, at 9:49 AM, Paul Winkler wrote:

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.

Not really, and that's why Zope 3 has avoided "through the web" code so far. I hope this avoidance continues at least in "the core", whatever that is, but I see rumblings every so often about why this is a can't-live-without thing (with which I strongly disagree). - C

On Fri, Dec 02, 2005 at 09:49:25AM -0500, Paul Winkler wrote:

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

Brain fart, sorry. There is no allowAny in ClassSecurityInfo or elsewhere. The quick-and-easy thing to do, if you don't want to create wrapper or derived class, somewhere in some Product code, do stuff like the following: from AccessControl import allow_class, allow_module, ModuleSecurityInfo # Allow scripts to *instantiate* a class. # Skip this if your scripts don't need to instantiate the objects. # Note that you can't call methods on it yet, keep reading... ModuleSecurityInfo('Products.MyProduct').declarePublic('myclass') # Allow unrestricted access to all *existing* instances # of a class. Now you can call its methods. # Note this *doesn't* automatically allow you to use # other objects returned by any of its methods, so # you may need to explicitly allow a bunch of other classes too... allow_class(myclass) # Allow scripts to import and use a function defined in # some product. This works just like allowing to instantiate classes. ModuleSecurityInfo('Products.MyProduct').declarePublic('myfunc') # Works for standard library or other modules on $PYTHONPATH too. ModuleSecurityInfo('urllib').declarePublic('urlopen') # Allow unrestricted imports and usage of an *entire* module: allow_module('mypackage.mymodule') # ... well, mostly. Sometimes that doesn't work and you need # to sprinkle in a few more declarations, e.g. for types # defined in C. # See for example # lib/python/Products/PythonScripts/module_access_examples.py # showing complications for e.g. the "re" module. -- Paul Winkler http://www.slinkp.com