Thanks, Steve. I have few questions below .... 8-) (I'm always better with questions than answers.) -- Loren From: "Steve Alexander" <steve@cat-box.net>
Hi Loren,
I'd be glad to listen to well considered proposals for how Xron should handle security.
Consider this a "straw man".
On installation, Xron creates a user in the root user folder called "XronUser".
Xron is resonsible for setting this user's password. Therefore, it is known to both the Xron product, and also to the root user folder.
When a Xron method is run, there is a property that indicates whether it is called anonymously, or authenticated as XronUser.
Is there a good reason not to always pass authentication in the request? The authentication property would have to be stored in the Schedule catalog, and I'd like to keep the Schedule as small as possible.
The Xron product could change the password of XronUser every day to a new random value.
That's more than folks do to maintain secrecy of the "superuser" password. Is the extra trouble worthwhile?
The domains associated with XronUser could be just localhost.localdomain (not sure about this). Or based on whatever the machine's host-name is (probably better).
At a virtual-hosted site, how could Xron know what the host-name is?
Site administrators can assign local roles to XronUser as necessary.
If Phillip Eby's proposed changes to the access file get included in some future version of Zope, XronUser could be included as one of these bootstrap users by simply writing to a file.
-- Steve Alexander Software Engineer Cat-Box ltd http://www.cat-box.net