On Thu, Nov 09, 2000 at 12:03:27PM -0500, Jeff Hoffman waxed eloquent:
On Thu, 9 Nov 2000, Charlie Wilkinson wrote: [snip...]
So what this boils down to is that as of v2.2.whatever, an acl_users folder apparently does not protect the folder it's in (parent folder), but only it's sibling objects and below. Meaning that instead of setting permissions on the parent object and being done with it, one now has to set permissions for each sibling. In my case that's 50 or more objects and I'm not done coding yet. Ouch! This *can't* be right, can it? I know there's a lot that's happened with the security model, so I'm really *really* hoping this is just a bug that's crept in.
This is the way Zope has always behaved, unless my memory is failing me. Here's a thought to consider: In your model, the root acl_users would have to appear _above_ the root folder (/) in the hierarchy for things to function correctly. As it stands, acl_users in the root folder affects all things in the root folder and below. As it stands, your acl_users (in acl_test) affects all things in your acl_test folder and below. This is consistent.
Thanks for your response Jeff. It seems we are in agreement. The scope of an acl_users folder needs to include its siblings and parent folder. The only logical alternative I can think of is if the functionality of acl_users, LoginManager, or whatever, was provided by some modular component of the parent folder itself, instead of being represented as just another object _in_ that folder. Anyway, I did a sanity check against v2.1.2 using these exact steps: 1. Create an access_test folder with user folder and user interface. 2. Navigate to security tab of access_test. 3. Create new role "User", and allow "User" to View Objects and Access Contents Info. Bar access by "Anonymous" by turning off "Acquire Permission Settings" for View Objects and Access Contents Info. 3. Create user "joe", password "blow", with role "User" 4. Bring up new browser window, enter the URL for access_test. In that scenario, joe can view anything within the acl_test folder, while anonymous users cannot, due to the objects within that folder acquiring their security settings from the acl_test folder itself. *That's* what I want! It's *not* what 2.2.cvs is doing. In fact it's even worse than previously described. After pulling down a completely new CVS image of Zope, I just happened to try visiting the root URL of the new site. Result? I was prompted for a password to visit the root (Welcome to Zope) page of a pristine, new Zope site. I think this must somehow all fit together. Unless there is something critical about the new security model that I have missed, it looks like there's a bug here.
If you have 50 or so objects, and setting permissions is the obstacle, simply write a Python Method (or DTML, if you prefer) to iterate over the 50 and tweak them. Then, you won't have to manually do the work through the management interface.
As I think you indicated above, the type of security/acquisition model that seems to be in place for 2.2.cvs poses far more serious problems (i.e., needing acl_users *above* the root folder) than just setting permissions on a bunch of modules. Thanks again Jeff. -cw- -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Charlie Wilkinson - cwilkins@boinklabs.com - N3HAZ Parental Unit, UNIX Admin, Homebrewer, Cat Lover, Spam Fighter, HAM, SWLer... Visit the Radio For Peace International Website: http://www.rfpi.org/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CLOBBER INTERNET SPAM: See!! <http://spam.abuse.net/> Join!! <http://www.cauce.org/> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ QOTD: "Bush is a big corporation disguised as a human being running for president." -- Ralph Nader on David Letterman (9/28/00)