Password Conflict (Restatement)
I appreciate the attempts at help I've gotten here to my earlier post. What is clear to me as I read them is that I have done a poor job of explaining my problem. My customer site has an acl_user folder at the top level. Only users whose names appear in that folder can update the site in any way. But the site includes a folder called Clearings which houses a set of Python scripts and HTML forms that together constitute an application which adds information to the Zope database (creates a folder and multiple documents). My client would like to allow anyone to whom he issues a password (which one of my scripts randomly generates on demand) the ability to run those scripts which update the site, but not do any other site updating or be able to see other aspects of the site. So when a person goes to the URL he gives them, they are challenged for a password. If they supply the proper password, they should then be allowed to visit the HTML forms which execute the Python scripts which in turn update the Zope database. I can't see how to use acl_users for this since I would have to either create a new user along with each new password generated or update the password for a pre-named user (like "client") in the acl_folder. Presumably even if I could figure out how to do that (which I haven't been able to do yet), I would need to create a new role for these individuals. My experience with Zope says that any time I run into something that feels this complex, I'm probably not thinking in Zope. I have received two suggestions. One suggests cutting the eight-character password into two slices, the first N characters being the user name and the remaining characters being the password for this user. But I think I would have to create a new user in the acl_users folder programmatically for this to have any chance of working and then I'd still have two problems: (1) I don't see any way to programmatically add users to acl_users; and, more importantly, (2) at any one time there can only be one such special user and password, so I'd have to know how to delete a user programmatically as well. This in turn would entail the need to know the name of the bogus user in a way that a script could discover it. Sounds convoluted to me. The other idea was to try an empty user name in Zope. I did. It's a no-go. Hopefully this was a clearer statement of the question and someone can help me. This entire site is ready for the user to take delivery and pay me but for this glitch!
[...]
My client would like to allow anyone to whom he issues a password (which one of my scripts randomly generates on demand) the ability to run those scripts which update the site, but not do any other site updating or be able to see other aspects of the site.
So when a person goes to the URL he gives them, they are challenged for a password. If they supply the proper password, they should then be allowed to visit the HTML forms which execute the Python scripts which in turn update the Zope database.
If I understand right, this kind of visitor does not need an identity, the visitor has just to provide the proper password. What I can think of in this context are Python scripts with Proxy Roles. I.e. You store the valid password or set of valid password to trigger the update action somewhere only accessible to someone with "Manager" role. Then You create the "update" form or the like with the password field, whose action is a python script, which checks if the password is valid, and if it is, triggers the update action on the ZODB (or whatever). Normally this would already fail when verifying the password, as one needs manager role to access them, and the user has no manager role. However You can give the script a "proxy role" as "Manager" via the "Proxy" tab in the ZMI. The statements in the script then will be executed as if the current user would have a manager role, and the statements should be executed successfully. More about proxy roles is in the Zope book, http://www.zope.org/Documentation/Books/ZopeBook/current/Security.stx section "Proxy Roles" near the bottom, in case You did never run into them. These proxy roles can cause security holes; if e.g. You make an error in the password verification allowing e.g. empty password to verify successfully, everybody can call the update code via this script. hope this helps, clemens
Now *this* sounds promising. I will look into scripts with Proxy roles. Wow. Amazing stuff. On Tuesday, November 26, 2002, at 05:20 PM, Clemens Robbenhaar wrote:
[...]
My client would like to allow anyone to whom he issues a password (which one of my scripts randomly generates on demand) the ability to run those scripts which update the site, but not do any other site updating or be able to see other aspects of the site.
So when a person goes to the URL he gives them, they are challenged for a password. If they supply the proper password, they should then be allowed to visit the HTML forms which execute the Python scripts which in turn update the Zope database.
If I understand right, this kind of visitor does not need an identity, the visitor has just to provide the proper password.
What I can think of in this context are Python scripts with Proxy Roles.
I.e. You store the valid password or set of valid password to trigger the update action somewhere only accessible to someone with "Manager" role.
Then You create the "update" form or the like with the password field, whose action is a python script, which checks if the password is valid, and if it is, triggers the update action on the ZODB (or whatever).
Normally this would already fail when verifying the password, as one needs manager role to access them, and the user has no manager role. However You can give the script a "proxy role" as "Manager" via the "Proxy" tab in the ZMI. The statements in the script then will be executed as if the current user would have a manager role, and the statements should be executed successfully.
More about proxy roles is in the Zope book, http://www.zope.org/Documentation/Books/ZopeBook/current/Security.stx section "Proxy Roles" near the bottom, in case You did never run into them. These proxy roles can cause security holes; if e.g. You make an error in the password verification allowing e.g. empty password to verify successfully, everybody can call the update code via this script.
hope this helps, clemens
On Tuesday 26 November 2002 05:04 pm, Dan Shafer wrote:
My customer site has an acl_user folder at the top level. Only users whose names appear in that folder can update the site in any way. But the site includes a folder called Clearings which houses a set of Python scripts and HTML forms that together constitute an application which adds information to the Zope database (creates a folder and multiple documents).
My client would like to allow anyone to whom he issues a password (which one of my scripts randomly generates on demand) the ability to run those scripts which update the site, but not do any other site updating or be able to see other aspects of the site.
So when a person goes to the URL he gives them, they are challenged for a password. If they supply the proper password, they should then be allowed to visit the HTML forms which execute the Python scripts which in turn update the Zope database.
I can't see how to use acl_users for this since I would have to either create a new user along with each new password generated or update the password for a pre-named user (like "client") in the acl_folder. Presumably even if I could figure out how to do that (which I haven't been able to do yet), I would need to create a new role for these individuals.
If I understand correctly, you have two mutually exclusive security zones. If possible, I would try to setup your folder structure to model that with two acl_users folders. Something like: new_client_root Clearings acl_users current_top_level acl_users HTH, Jeff
participants (3)
-
Clemens Robbenhaar -
Dan Shafer -
Jeff Youel