From: clayton c. <cc...@ca...> - 2001-03-30 15:00:10
|
Alain, > http://www.phpsecurepages.f2s.com/ > > This looks really good ! yes, but the problem is granularity. this only deals with coarse-grained, page-level access. we need (i think) a generalized system to deal with arbitrary objects in the system (can user x or group g do y with object a) ----- Original Message ----- From: "Alain Fontaine" <al...@va...> To: <php...@li...> Sent: Thursday, 29. March 2001 17:29 Subject: RE: [Phpwebsite-developers] Integrated User/Group & Permissions > Hi, > > http://www.phpsecurepages.f2s.com/ > > This looks really good ! > > Take a look. > > Alain > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
From: Todd O. <to...@da...> - 2001-03-30 15:45:57
|
> yes, but the problem is granularity. this only deals with coarse-grained, > page-level access. we need (i think) a generalized system to deal with > arbitrary objects in the system (can user x or group g do y with object a) I agree that we need per object instance level access control. This means that you may only have one forum plug-in, which the site admin gets to control, but two forum instances that require separate access control by different users. This is part of my roadmap. --Todd |
From: Todd O. <to...@da...> - 2001-03-31 03:49:33
|
You can find the best access control system I've seen, in Zope. http://www.zope.org Just download version 2.3.1, which was released today, and look in the following location for the Python files that define Zope's access control granularity. Zope-2.3.1-src\lib\python\AccessControl\ Zope is a great product, but it has a steep learning curve. There's too much overhead to be used for small sites where you just want to hack out some scripts. Zope allows a custom template for every object, which is great except when you don't want it. Making some site wide changes in a Zope can be painful. Zope is a worthy competitor to what we are doing here and contains some fuctionality that will never appear in phpWS, like versioned changes to a live site (very cool). Digital Creations has 30+ developers working full time on Zope right now, including von Rossum of Python. After much consideration, I had to leave Zope because of the multiple organization support issue (it wasn't designed that way). All that said, there are lots of good ideas in the Zope code that would make phpWebSite a better product. Here's AccessControl.txt from directory above: --Todd --------------------- Security Architecture --------------------- Users ----- Objects representing users may be created in Principia User Folder objects. User objects maintain the information used to authenticate users, and allow roles to be associated with a user. Permissions ----------- A "permission" is the smallest unit of access to an object, roughly equivalent to the atomic permissions seen in NT: R (Read), W(Write), X(Execute), etc. In Principia, a permission usually describes a fine-grained logical operation on an object, such as "View Management Screens", "Add Properties", etc. Different types of objects will define different permissions as appropriate for the object. Types of access --------------- A "type of access" is a named grouping of 0 or more of the permissions defined by an object. All objects have one predefined type of access called Full Access (all permissions defined by that object). A user who has the special role "Manager" always has Full Access to all objects at or below the level in the object hierarchy at which the user is defined. New types of access may be defined as combinations of the various permissions defined by a given object. These new types of access may be defined by the programmer, or by users at runtime. Roles ----- A role is a name that ties users (authentication of identity) to permissions (authorization for that identity) in the system. Roles may be defined in any Folder (or Folderish) object in the system. Sub folders can make use of roles defined higher in the hierarchy. These roles can be assigned to users. All users, including non-authenticated users have the built-in role of "Anonymous". Principia objects allow the association of defined roles with a single "type of access" each, in the context of that object. A single role is associated with one and only one type of access in the context of a given object. Examples -------- User Object1 o has the role "RoleA" o has given "RoleA" Full Access Result: the user has Full Access to Object1. User Object2 o has the role "RoleA" o has given "RoleB" Full Access o has given the role "RoleA" View Access, a custom type of access that allows only viewing of the object. Result: the user has only View Access. Notes ----- All objects define a permission called "Default permission". If this permission is given to a role, users with that role will be able to access subobjects which do not explicitly restrict access. Technical --------- Objects define their permissions as logical operations. Programmers have to determine the appropriate operations for their object type, and provide a mapping of permission name to attribute names. It is important to note that permissions cannot overlap - none of the attributes named in a permission can occur in any of the other permissions. The following are proposed permissions for some current principia objects: Folder o View management screens o Change permissions o Undo changes o Add objects o Delete objects o Add properties o Change properties o Delete properties o Default permission Confera Topic o View management screens o Change permissions o Undo changes o Add objects o Delete objects o Add properties o Change properties o Delete properties o Default permission o Change Configuration o Add Messages o Change Messages o Delete Messages Tabula Collection o View management screens o Change permissions o Undo changes o Add objects o Delete objects o Add properties o Change properties o Delete properties o Default permission o Change schema o Upload data o Add computed fields o Change computed fields o Delete computed fields Document/Image/File o View management screens o Change permissions o Change/upload data o View Session o View management screens o Change permissions o Change session config o Join/leave session o Save/discard session Mail Host o View management screens o Change permissions o Change configuration To support the architecture, developers must derive an object from the AccessControl.RoleManager mixin class, and define in their class an __ac_permissions__ attribute. This should be a tuple of tuples, where each tuple represents a permission and contains a string permission name as its first element and a list of attribute names as its second element. Example: __ac_permissions__=( ('View management screens', ['manage','manage_menu','manage_main','manage_copyright', 'manage_tabs','manage_propertiesForm','manage_UndoForm']), ('Undo changes', ['manage_undo_transactions']), ('Change permissions', ['manage_access']), ('Add objects', ['manage_addObject']), ('Delete objects', ['manage_delObjects']), ('Add properties', ['manage_addProperty']), ('Change properties', ['manage_editProperties']), ('Delete properties', ['manage_delProperties']), ('Default permission', ['']), ) The developer may also predefine useful types of access, by specifying an __ac_types__ attribute. This should be a tuple of tuples, where each tuple represents a type of access and contains a string name as its first element and a list of permission names as its second element. By default, only "Full Access" is defined (by the RoleManager mixin). If you wish to override __ac_types__ to provide convenient types of access, you must always be sure to define "Full Access" as containing the names of all possible permissions for your object. Example: __ac_types__=( ('Full Access', map(lambda x: x[0], __ac_permissions__)), ('Change', ['Add Objects', 'Add Properties', 'Change Properties']), ) Developers may also provide pre-defined role names that are not deletable via the interface by specifying an __ac_roles__ attribute. This is probably not something we'll ever use under the new architecture, but it's there if you need it. Example: __ac_roles__=('Manager', 'Anonymous') |
From: clayton c. <cc...@ca...> - 2001-03-31 08:55:50
|
Todd, the code i sent you can be made to accomodate parts of what Zope does, with the exception of heirarchical permissions. with its user-groups and the general permissions code, it can support named, object-level permissions which can be assigned to a user (registered or unregistered), group, and roles within groups. One deviation from Zope roles is the notion of "actions" - or operations permissible for a role. one can assign multiple actions per role. it is flexible enough to allow the user to choose what style of permissions s/he wishes to employ. ACS in its later versions began to implement a more layered user (hence permissions) structure, but based on my reading of the code, it really would take a well tuned back end to deal with the type of queries they needed to support it. definitely not for your garden variety ISP. thats one of the reasons i stopped tracking it at version 3.xxx. The Zope architecture is indeed nice, but i think they have custom serialization to handle their data model. i'll give the AccessControl.txt file a read .... |
From: Todd O. <to...@da...> - 2001-04-03 02:00:20
|
Clayton Collie wrote the following on Saturday: >Ars Digita Community System >ACS in its later versions began to implement a more layered user (hence >permissions) structure, but based on my reading of the code, it really would >take a well tuned back end to deal with the type of queries they needed to >support it. definitely not for your garden variety ISP. thats one of the >reasons i stopped tracking it at version 3.xxx. The Zope architecture is >indeed nice, but i think they have custom serialization to handle their data >model. The ACS permission scheme looks very nice and very flexible. We would probably need to streamline the code some for performance reasons, but it definately gives us a level of granularity seen few other places. How does everyone else feel about this? --Todd |
From: clayton c. <cc...@ca...> - 2001-04-03 14:06:59
|
We are nowhere near needing something like this, but i think its something we should watch ... http://ibm.digiconcept.net/netautor.basic/index.html and its written in PHP ... |
From: clayton c. <cc...@ca...> - 2001-03-29 23:16:26
|
Todd, i'll send it out tomorrow as im rushed for the rest of the day. > Anyway, http://www.openacs.org has the TCL, Aolserver, Postgresql version, > The OpenACS group worked hard moving the Oracle > stored procedures from ACS to the TCL side of OpenACS. thats what i had to do to try and make things more DB independent. > I won't digress about how I think Python is > the best language around) that my next "P" language to tackle, after Perl (not pretty, but good for "heavy lifting") and PHP. everything ive read suggests that its a thing of beauty. > Since my goal for PHP is to have multiple sites within the same installation > (and same database tables), then an access control list becomes increasingly > more important. Multi-sites in the same DB shouldnt be a problem at all. Permissions are based on object Ids (primary keys), so it doesnt matter which site they belong to. The permission system is a general framework you use to grant/revoke/check access to any object in the system. it can be tailored to fit many scenarios. (its a little clearer if you look at the object model and the source code) >ACS's strength is definitely its data model, which will benefit anyone who > studies it. Absolutely ! |
From: Brian W. B. <br...@ap...> - 2001-03-29 23:12:51
|
>> As far as database abstraction goes, let me cast my vote for PEAR. >> Smarty uses PEAR (although not for databases), phplib will be >> integrated into PEAR, and I believe PEAR will become the standard, >> whether phpWebSite adopts it or not--it's in the PHP distribution >> already. Having reviewed the classes, I believe they will serve us >> well. Yes, PEAR is looking good. -- Brian W. Brown Internet Systems Architect, ESS Student Development Room 269, John Thomas Hall Appalachian State University Boone, NC 28608 vox: 828-262-7124 fax: 828-262-2585 |
From: clayton c. <cc...@ca...> - 2001-03-27 18:38:29
|
i've been lurking for the most part (actually quite busy at the moment). but since much discussion is occurring about revving up production, i thought i'd ask about where people see this project heading. i apologize, but i haven been able to find the PhpWebsite Roadmap in my inbox, so this may have already been addressed. particularly, is phpWS primarily geared toward the Weblog/news posting/Slashdot type of portal or do you see it evolving into a more generalized community oriented portal system ? the reason im asking is because i have specific needs for a site im developing, that functions more along the lines of a community oriented site with a strong focus on user input and collaboration. on the way to spec'ing it out i picked up a great deal about the basics of constructing such a site (essentially that it has to be built from the ground up to be that way, so good modular architecture and database design is crucial). a project that seems to be oriented this way (in architecture if not in presentation) is ezPublish. alas, i try to do too many things in my limited time, so i've been looking for fellow travelers to see if we could push each other further. if phpWS is headed that way, i may be able to give a bit of code/design assistance. otherwise i'll just use it as is for a few other sites i need to set up, and keep working on the big one.. keep up the good work <::subText::> |
From: Todd O. <to...@da...> - 2001-03-27 18:53:23
|
My vision for phpWebSite is definitely community oriented and much more general than just a slashdot-like. From my experience with the project most everyone holds the same view. The Roadmap is not yet complete, but Brian would like it to be complete by next week, which is when some decisions should be made. --Todd |
From: Karsten D. <k.d...@fi...> - 2001-03-29 18:39:50
|
On Tue, Mar 27, 2001 at 08:03:20PM +0200, Alain Fontaine wrote: > * Use underscores in function names > Why ? If ever phpWebSite will be developed in an OO approach, why not use > the "java style" of function and variable naming ? setThisThat(), > getThisThat(), displayStuff() etc look much better to me than > set_this_that() and so on :) Well, I think we will stick with the underscores. See some other emails for some reasons. Basically: PHP does it this way (mysql_query, etc.), so we do it as well. This just isn't Java :-) And most of the code is written that way already. > *Try to avoid unnecessary file unclusions (see config.php and mainfile.ph= p) > This is of course always true, as an unnecessary file inclusion is always= to > be avoided per definition :). However, using include_once() and > require_once() could help avoiding problems a bit. True, *_once() should help. But we should nevertheless try to remove as many of these calls as possible, I think. > For the rest, I think the documentation and guidelines you put up will be > invaluable to the development team - good work. Thanks! I hope some more people looked at the suggested coding style and all agree to it. There is one more thing: I wrote "using tabwidth 8" which is (IMHO) the emacs default setting and preferred by K&R and the linux core hackers and many more. Do all agree on that? And what about the curly braces thing? Do we really put them on an otherwise empty line? I wrote that because I had the impression it was done that way in the code until now. I prefer putting the opening one last on the line, and the closing one first, as follows: foo() { bla } What do you think about that? (See /usr/src/linux/Documentation/CodingStyle if available on your computer for some even more detailed piece about coding style :-) Did anybody ever try to use GNU indent on PHP source code? Does that work? Regards, Karsten --=20 fishfarm - Karsten Dambekalns Echternstr. 73 - 38100 Braunschweig Tel. +49 531 1232902 mailto:k.d...@fi... Fax. +49 531 1232906 http://www.fishfarm.de/ ----------------------------------------------------- |
From: Todd O. <to...@da...> - 2001-03-29 19:27:45
|
I normally only indent (2) spaces, but have forced myself to follow the PEAR standard, which is (4) spaces. I think we should use the PEAR coding standards. http://pear.php.net will get you to the standards. --Todd |