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!