Hi, I have a working pyhton script in the ZODB that searches for members and is called by a xmlrpc client. Security is only needed based on source IP address, so Anonymous can execute it, but the script has an Authenticated proxy role. I would like to convert this script to an Exteral Method in $INSTANCE_HOME/Extensions. This basically works, but I cannot see any way to specify the proxy role. And when it is not specified the script obviously does not work. After some googling, I tried to make a <scriptname>.metadata file with: [default] proxy=Authenticicated But that does not seem to work... - Is the .metadata supported for external methods? - Is there another way to set proxy roles in external methods? TIA, -- __________________________________________________ "Nothing is as subjective as reality" Reinoud van Leeuwen reinoud.v@n.leeuwen.net http://www.xs4all.nl/~reinoud __________________________________________________
On 10 Oct 2005, at 16:49, Reinoud van Leeuwen wrote:
I would like to convert this script to an Exteral Method in $INSTANCE_HOME/Extensions. This basically works, but I cannot see any way to specify the proxy role. And when it is not specified the script obviously does not work.
Have you *tried* that? External methods don't need proxy roles. They are "trusted code". jens
On Mon, Oct 10, 2005 at 05:06:22PM +0100, Jens Vagelpohl wrote:
On 10 Oct 2005, at 16:49, Reinoud van Leeuwen wrote:
I would like to convert this script to an Exteral Method in $INSTANCE_HOME/Extensions. This basically works, but I cannot see any way to specify the proxy role. And when it is not specified the script obviously does not work.
Have you *tried* that? External methods don't need proxy roles. They are "trusted code".
yes. I I run the script from the ZMI logged in as admin it finds members, but if I try it from an XMLRPC client it does not -- __________________________________________________ "Nothing is as subjective as reality" Reinoud van Leeuwen reinoud.v@n.leeuwen.net http://www.xs4all.nl/~reinoud __________________________________________________
Are you using CMF/Plone? -aj --On 10. Oktober 2005 19:18:00 +0200 Reinoud van Leeuwen <reinoud.v@n.leeuwen.net> wrote:
On Mon, Oct 10, 2005 at 05:06:22PM +0100, Jens Vagelpohl wrote:
On 10 Oct 2005, at 16:49, Reinoud van Leeuwen wrote:
I would like to convert this script to an Exteral Method in $INSTANCE_HOME/Extensions. This basically works, but I cannot see any way to specify the proxy role. And when it is not specified the script obviously does not work.
Have you *tried* that? External methods don't need proxy roles. They are "trusted code".
yes. I I run the script from the ZMI logged in as admin it finds members, but if I try it from an XMLRPC client it does not
-- __________________________________________________ "Nothing is as subjective as reality" Reinoud van Leeuwen reinoud.v@n.leeuwen.net http://www.xs4all.nl/~reinoud __________________________________________________ _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
--On 10. Oktober 2005 17:49:20 +0200 Reinoud van Leeuwen <reinoud.v@n.leeuwen.net> wrote:
I would like to convert this script to an Exteral Method in $INSTANCE_HOME/Extensions. This basically works, but I cannot see any way to specify the proxy role. And when it is not specified the script obviously does not work.
ExternaMethod run without restriction so there is usually to need for proxy roles (there are no proxy roles) for ExternalMethods. -aj
I'm trying to allow users to delete objects that have been accidentally created. I have criteria for what that means, but since I *DO NOT* want them to delete object except by this method, I want to avoid granting "Delete objects" to them (non-Managers). Can this even be done? At the base level, "Delete objects" is a hard-coded requirement of the ObjectManager.manage_delObjects() function. One solution that I considered is to create a new role with the privilege, then within my ExternalMethod: - grant the role to the user for the folder, - delete the object, - remove the role for that user for the folder But this seems overly tedious, and a problem if the script terminates before removing the role. Similarly, it could use the Manager role in the same scenario, but this seems dangerous. Any insights appreciated, Nikko PS: This seems on-topic, but using the code shown did not seem to have any effect: http://mail.zope.org/pipermail/zope/2003-October/142887.html
Nikko Wolf wrote at 2005-10-14 15:37 -0600:
I'm trying to allow users to delete objects that have been accidentally created. I have criteria for what that means, but since I *DO NOT* want them to delete object except by this method, I want to avoid granting "Delete objects" to them (non-Managers).
Can this even be done? At the base level, "Delete objects" is a hard-coded requirement of the ObjectManager.manage_delObjects() function.
Usually, an "External Method" is not restricted by Zope's security. Unless "manage_delObjects" does not perform an additional internal check (I think, it does not), your "External Method" can use it to delete objects. BTW: Often, it is more faster simply to try something than to post a question to the mailing list and wait for the answer. Your question above is such a case ... -- Dieter
Dieter Maurer wrote:
Nikko Wolf wrote at 2005-10-14 15:37 -0600:
I'm trying to allow users to delete objects that have been accidentally created. I have criteria for what that means, but since I *DO NOT* want them to delete object except by this method, I want to avoid granting "Delete objects" to them (non-Managers).
Can this even be done? At the base level, "Delete objects" is a hard-coded requirement of the ObjectManager.manage_delObjects() function.
Usually, an "External Method" is not restricted by Zope's security.
Unless "manage_delObjects" does not perform an additional internal check (I think, it does not), your "External Method" can use it to delete objects.
My question stemmed from the fact that (for reasons I cannot not duplicate), I was repeatedly getting Unauthorized exceptions using the manage_delObjects() function. Thus, I moved the functionality into an External Method, intending to avoid the restrictions. But even there, throughout changes too numerous to remember now, the Unauthorized problem persisted. Then, after snooping around I found code in zope/lib/python/OFS/ObjectManager.py that set __ac_permissions__ with an entry: ('Delete objects', ('manage_delObjects',)) ... hence my thought was that the ObjectManager class had the requirement builtin at the source code level. Even trying new security context (created from within the External Method) did not work. After many hours of effort and debugging, I find that it works in a "Script (Python)" with precisely the same code that I (thought I) used originally. Obviously, something is different, but unless it was a subtle typo that compiled correctly and worked (but not as desired) I cannot fathom what has changed.
BTW: Often, it is more faster simply to try something than to post a question to the mailing list and wait for the answer. Your question above is such a case ...
Indeed, I know that well. I *had* tried a multitude of variations before sending; and I'd originally included details in the first posting, but deleted it before I sent it since the question seemed to stand on its own. Thanks anyway, Nikko
Nikko Wolf wrote:
I'm trying to allow users to delete objects that have been accidentally created. I have criteria for what that means, but since I *DO NOT* want them to delete object except by this method, I want to avoid granting "Delete objects" to them (non-Managers).
Have the "delete process" done in a python script or external method. Only give "view" permission to that method to people who you want to be able to delete objects. If it's a python script, give it a Proxy role that has the "Delete objects" permission mapped, and you'll be fine :-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Nikko Wolf wrote:
I'm trying to allow users to delete objects that have been accidentally created. I have criteria for what that means, but since I *DO NOT* want them to delete object except by this method, I want to avoid granting "Delete objects" to them (non-Managers).
Have the "delete process" done in a python script or external method. Only give "view" permission to that method to people who you want to be able to delete objects.
If it's a python script, give it a Proxy role that has the "Delete objects" permission mapped, and you'll be fine :-)
That was my expectation too, but alas -- it does not work for me. Have you specifically tried this? ==== Set up: - Plone Site with "Delete objects" permission granted only to Manager (not inheriting privs) - (Plone) Folder "abc" with an object "xyz" under the Plone Site (inheriting privs) - The following "Script (Python)" named "nuke" and with "Manager" proxy role. - Non Manager user - Load URL: {plone-root}/abc/xyz/nuke ==== Browser shows: Insufficient Privileges You do not have sufficient privileges to view this page. If you believe you are receiving this message in error, please send an e-mail to" ==== The events.log shows: 2005-10-17T16:16:34 ERROR(200) SiteError http://localhost:8080/PloneRoot/abc/xyz/nuke Traceback (most recent call last): File "/usr/local/zope/lib/python/ZPublisher/Publish.py", line 101, in publish request, bind=1) File "/usr/local/zope/lib/python/ZPublisher/mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "/usr/local/zope/lib/python/ZPublisher/Publish.py", line 39, in call_object result=apply(object,args) # Type s<cr> to step into published object. File "/usr/local/zope/lib/python/Shared/DC/Scripts/Bindings.py", line 306, in __call__ return self._bindAndExec(args, kw, None) File "/usr/local/zope/lib/python/Shared/DC/Scripts/Bindings.py", line 343, in _bindAndExec return self._exec(bound_data, args, kw) File "/usr/local/zope/lib/python/Products/PythonScripts/PythonScript.py", line 324, in _exec result = f(*args, **kw) File "Script (Python)", line 16, in mlt File "/usr/local/zinstance/Products/CMFPlone/PloneFolder.py", line 306, in manage_delObjects raise Unauthorized, ( Unauthorized: Do not have permissions to remove this object ==== The script is: ## Script (Python) "nuke" ##bind container=container ##bind context=context ##bind namespace= ##bind script=script ##bind subpath=traverse_subpath ##parameters= ##title=My Test Script ## from Products.PythonScripts.standard import html_quote objid = context.getId() folder = context.aq_inner.aq_parent mylog = folder.plone_log ##### ## DELETION CRITERIA CHECKS OMITTED #### # So, now we delete it... member = context.portal_membership.getAuthenticatedMember() mylog( "%s deletes (%s) from (%s)" %\ (member.id, context.absolute_url(), folder.absolute_url())) resp = folder.manage_delObjects( [objid] ) mylog( "folder.{%s}.manage_delObjects(['%s'] = {%s}\nCTX=%s" % (folder.absolute_url(), objid, folder.dumpIt( resp ), folder.absolute_url())) mylog( "Remaining: " + str(folder.objectIds()) ) # Set 'text' for the portal_status_message text = "No exceptions deleting '%s'" % objid if objid in folder.objectIds(): text += " / ID is still there" else: text += " / ID is gone" if context in folder.objectValues(): text += " / OBJECT is still there" else: text += " / OBJECT is gone" context.REQUEST.RESPONSE.redirect( folder.absolute_url() + '?portal_status_message=' + html_quote(text))
Nikko Wolf wrote:
That was my expectation too, but alas -- it does not work for me. Have you specifically tried this?
Yes, many times...
==== Set up: - Plone Site with "Delete objects" permission granted only to Manager (not inheriting privs) - (Plone) Folder "abc" with an object "xyz" under the Plone Site (inheriting privs)
Well, you're using Plone, so you're on your own. It or CMF may do some other funky permissions checks on delete which are screwing you up...
==== Browser shows: Insufficient Privileges
You do not have sufficient privileges to view this page. If you believe you are receiving this message in error, please send an e-mail to"
File "/usr/local/zinstance/Products/CMFPlone/PloneFolder.py", line 306, in manage_delObjects raise Unauthorized, ( Unauthorized: Do not have permissions to remove this object
You should install VerboseSecurity if using Zope 2.7 or enable in in zope.conf if using Zope 2.8, it will tell you more... But, look at that traceback, it's coming from PloneFolder.py (suprise, suprise) so you'll have to go there and find out what funky nastiness is lurking ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Nikko Wolf wrote at 2005-10-17 16:21 -0600:
... File "/usr/local/zinstance/Products/CMFPlone/PloneFolder.py", line 306, in manage_delObjects raise Unauthorized, ( Unauthorized: Do not have permissions to remove this object
This obviously is the Plone implementation of "manage_delObjects" -- and it apparently performs an explicit check (unlike Zope's "manage_delObjects"). You should ask Plone related questions on the Plone (and not the Zope) mailing list. Things can be quite different in Plone land (as e.g. for "manage_delObjects"). -- Dieter
participants (6)
-
Andreas Jung -
Chris Withers -
Dieter Maurer -
Jens Vagelpohl -
Nikko Wolf -
Reinoud van Leeuwen