|
Friday 14 February 2003 9:11:52 am
In ezp 2.2.*, it was possible to define authorisation on content object-level. As a creator of content, you could decide for each individual folder or article, which users or user groups should be granted which kind of access to your content. With the introduction of ezp3, authorisation on content object-level has been eliminated. The substitutes available (authorisation-rules based on module-functions, with limitation opportunities to sections, classes and owners) are no adequate substitutes for content object-level authorisation, because their scope is either an ABSTRACT scope (module or classes) and therefore too general, or too limited (owners, sections) in order to establish access control for content. If ez systems sold cars, I clearly would not buy such a car, since none of the keys they currently offer is appropriate to protect my car in a usual manner: The "module"-key allows you to unlock either all cars of ezsystems or, if restricted by a "class"-policy, this key still allows you to unlock much too many cars, say - all roadsters or vans. The "owner"-key, while pretty good to limit access to your car radically, has to be fixed irreversibly to your body (fingerprint key) and so even your wife or best friend could not use it to drive your car some day. The "section"-key is not a car-key at all. Instead, it is the advice to buy a car without locks and park it on guarded parkings only. Unfortunately, anyone who passes the guard of your section-parking without being rejected, may afterwards choose to enter an arbitrary unlocked car on this site. So the "section"-guarded parking approach is suitable only in situations where you know you can trust everyone who enters the section not to enter another one's car or where every car is meant to be accessible to any visitor. My cars a clearly not of that kind. The ONE SIMPLE THING missing in ezp3 is a kind of car key which unlocks only the car you own and can be distributed to a defined group of persons according to your preferences as car-keeper. The role model of ezp3, although it is a great step towards a professional authorisation scheme, is not yet completely implemented in it's function to control user's or user-group's access to content. We can assign roles to users. This is pretty important to decide what kind of action a user should be allowed to perform on your site in general, e.g. "DRIVER LICENSE" or "BUS DRIVER LICENSE". But the assignment of roles to users should not be misused to define the access control to objects, too. Here is the grave misconception in current ezp3. Everybody who enters your site with a DRIVER LICENSE is entitled to take away any car he or she likes without further control. The ezp-devs have tried to cope with this through POLICY LIMITATION: This means that you can confine your DRIVER LICENSE to, say BIKES or something. However, as mentioned above, even a limited BIKE DRIVER LICENSE is NOT A KEY TO BIKES and your bike drivers may still take away any bike they like on your site. What we simply need is an assignment of roles to content objects in order to accomplish the transitivity between users and content in authorisation logic and to obtain the desired car keys again.
I think it is pretty clear what this comment is about.
I am looking forward to further comments on this.
|