Judson Lester wrote: <snip/> > Resource based AC seems like an administrative nightmare. With Cocoon as it is today I agree, for resource based AC to be atractive there must be a underlying CMS that all resources are accessed through. In this scenario the CMS is resposbible for AC of resources and Cocoon is responsible for calculating access rights for the composition of resources.
> Bad enough to have to specify somewhere (and hopefully in one place! > - as per your suggestion there's no way to guarantee this) exactly what > users have what rights on what resources. I guess you refer to the SQL query example? I am afraid it was better as an argument against than for my conclusions ;) I think for hierarcical datastructures: file systems, XML DB, LDAP it is fairly straightforward (at least conceptually) to protect with AC concepts like those in WebDAV ACL. It would however be quite hard to write an SQL transformer that draws any conclusions about access rights from a SQL query, in this case request URI protection is probably the only plausible option. > In fact, I forsee establishing groups that have access rights to > the resources needed for any one URI, and adding users to them, WebDAV ACL allow you to group users, as well as resources and operations in any hierachy you like. > Now, while this does demonstrate that resource based AC would be more > flexible, I can't really see it flexing outside of URI AC's > domain and still > being correct. I can't say I'd see it being worth altering the > underpinnings > of the engine to provide this level of AC. Flexiblity is not the main issue. It is that (IMHO) in most cases the content (the resources) are more natural units of protection than the various views of them (the request URI:s), so I would prefer a resource based AC system, but as this would require integration with a CMS, request URI based AC is much more realistic as a short term goal. /Daniel Fagerström --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
