Loren Stafford wrote:
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.
I can't think of a concrete example of when I'd want to have a Xron method called with no authentication, when authentication is available. XronUser would be a privilaged user, and it might be useful to run scheduled methods without using that privilage. However, in the 2.2 security model, you can drop privilage using proxy roles, so I don't think your suggestion above is a limitation. So, no, I can't see a good reason not to always pass authentication in the request.
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?
I put this in as an example to illustrate that only the Xron product, and the Zope root user folder need to know the XronUser password. You're right, it really doesn't need to change every day :-) However, there should be manage_... method in Xron that will change the password to a new random value. Then, if people wanted the password changed every day, they could use a Xron DTML Method to do it :-) Perhaps also a button somewhere in the Xron product, or in the Schedule, to call the manage_resetXronPassword method.
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?
Xron must know (in some sense) what the host name is now, in order to use ZClient to call a Xron DTML Method. I guess this is because the URL to use comes from absolute_url() in Zope. I'm using Xron 0.0.9 on a virtual-hosted site, and it works. However, restricting a User's domains doesn't work as I would expect. The configuration is ZServer behind Apache+ProxyPass. If I put any value in the "domains" field of a User, other than "127.0.0.1", that User cannot log in at all. I haven't looked into this particularly yet. In AccessControl/User.py, login restriction by domain works using REMOTE_HOST and REMOTE_ADDR from the REQUEST. I sent myself an email from a Xron DTML Method on two Zope 2.2.1b1 machines, one just running ZServer, the other virtual-hosted as described above. In the case of the virtual-hosted server, I get emailed REMOTE_ADDR 127.0.0.1 In the case of the bare ZServer, I get emailed REMOTE_ADDR my_server's_ip_address Also, for the virtual server, ZClient seems to choose an appropriate HTTP_HOST. So, it seems that the correct domain restriction to use depends on just how you're using ZServer. I can think of three ways around this: 1: Don't bother restricting by domain for XronUser. 2: Allow a Manager to configure what domains XronUser may log in from. 3: Use ZClient to call a method in Xron. Xron inspects the REQUEST passed for this method, extracts the REMOTE_ADDR and REMOTE_HOST, and uses one of these as the domain restriction. If you go with 3, there will need to be some button in Xron's management interface to re-determine the correct domain to use. If I were writing the software, I'd choose 2, and let the Manager of a site make the decision. -- Steve Alexander Software Engineer Cat-Box ltd http://www.cat-box.net