[Zope] Password Conflict (Restatement)

[Dan Shafer]

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!