On Wed, 7 Jul 1999, David Jacobs wrote:

Provide for positive and negative authorizations. * We may want to give a role Employees access to a method, but not if the user is also in the role Bad Boys.

Provide for resolution rules for when positive and negative authorization conflict. * (e.g. lower in the object hierarchy overrides inherited auths, negative overrides positive, order dependent)

Allow time restrictions on user/role associations or method/role associations (duration or cyclical restrictions) This could be probably done quite easily by providing a different augmented User Folder. Allow actions to be associated with an authorization event. * on success (e.g. write audit entry in log) * on failure (e.g. write audit entry in log and call routine that checks for excessive failures and pages sys admin if over the threshold.send email) This could be added when some poor soul does the rewrite of error handling in ZPublisher to work correctly with the standard_error_message document.

Allow expressions that include object values to play in the authorization decision. * Given an expense voucher (EV) object, a 1st Level Manager can 'sign' (an EV method) if the EV.amount is less than $2500 and the EV.author is not the AUTHENTICATED_USER. Well, this would quite complicate the existing permission model. Don't know if the complications for ALL users outweigh the convience for SOME users.

What do people think? Does this functionality sound useful? Do certain features call louder than others. I believe these features will make Zope MUCH more attractive for developing intranet applications, which typically have much more complex security requirements than public web sites do. Probably, but more complicated applications will always have to be scripted: if you add feature A,B and C today, then you will discover that you still need feature D.

So IMHO, even A, B and C should be scripted, especially, when they are not of use for MOST users.

I realize that most if not all of these features can be accomplished by coding in dtml. I would like to see much of that abstracted out into the security interface so that security policies can be more easily changed. Again, create a specialized User folder, that can hold your security parameters. After that you can change the parameters easily enough :)

I also realize that besides implementation, there is also the problem of coming up with a reasonable user interface that does not swamp the average person with possibilities. Good default behavior is necessary, with the full complexity of options only showing if the application designer asks for it. That's the difficult one. Even worse, Z users also tend to write a little bit of Python (on the principle, that some things are difficult to impossible in DTML, e.g. circumventing Acquisition, which sometimes simplifies things). So your implementation should have also an API that is simple.

I've started familiarizing myself with the source code but have a ways to go. Obviously I would be making lots of changes in the access control directory, but it looks like a lot of the security framework is also embedded into the Zope objects like Folder and Document Objects. Any tips on code to pay special attention to or code that I can safely ignore would be greatly appreciated. 1.) Fool around with Zope. 2.) Learn Python (if you do not know it well.) 3.) Learn to use ZPublisher alone. This should give you the base understanding about security with Zope. 4.) Read source code.

Andreas -- Win95: n., A huge annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.