[geeklog-devel] ACL follow-up

[Dwight Trumbower]

I should be able to do it. Wednesday night I hope to be geeklog night.



At 03:46 PM 6/23/2003, you wrote:
>Right, when you log in, all the groups and permissions you have would go 
>back to the calling application and stored in a user object that is 
>persisted in the session.  That said, the SEC_inGroup, SEC_hasAccess type 
>functions are actually part of the A&A client only.  The server is only 
>concerned with returning the values for a given user on a given application.
>
>I think we are on the same page here.  I will start making the 
>changes.  Dwight, you may want to update the datamodels accordingly (or do 
>you want me to do it?).
>
>--Tony
>
>Vincent Furia wrote:
>>Before I posted to all this to the web site.  I just wanted to respond to 
>>Tony's input and questions and make sure no one else has anything else to 
>>say.  If not I'll try to get this up on geeklog.net tomorrow. I'll embed 
>>furhter comments in Tony's email below:
>>Tony Bibbs wrote:
>>
>>>Vinny, I think I'm right on with you on the ACL system.  However, one 
>>>point of disagreement is that notion you support that EDIT + ADMIN = 
>>>OWNER.  That isn't true, we should track the creator of the item as the 
>>>owner. Ok, wait, now that I actually read the SQL you gave, you do have 
>>>a uid field so I have to assume you are tracking it as I suggested. 
>>>Never mind ;-)
>>I think that "author" (the original creator of the item) should be stored 
>>by the item along with any other information.  My reference to OWNER 
>>above is more like being the owner of a file under unix.  The owner has a 
>>large amount of control over the file.  The big difference is that this 
>>ACL scheme could support multiple owners for a single item.
>>
>>>Now, to adequately address the real possibility of having multiple ACL's 
>>>let me give a high level objet model:
>>>
>>>ACL_Factory: Class that creates ACL libraries on the fly.  The specific 
>>>ACL system to use is determined by a config.php setting.  All this 
>>>object does is instantiate the right ACL system and returns it.
>>This might be over kill, a simple configuration variable pointing to the 
>>version of BaseACL you wish to use would probably be sufficient.  But if 
>>you'd prefer to go this I don't see any obsticles.
>>
>>>
>>>BaseACL: Abstract class (not instantiated directly) that all ACL systems 
>>>inherit from.  The methods here would be similar to the ones found in GL 
>>>1.3.x's lib-security.php (i.e. getUserGroups, inGroup, hasAccess, 
>>>getUserPermissions, etc).
>>Always a good idea in OOP programming.
>>
>>>
>>>Default_ACL: This extends BaseACL by implementing the system that Vinny 
>>>is talking about.
>>Cool.
>>
>>>
>>>For those who care, using the factory design pattern now lets you 
>>>implement any ACL system  All it has to do is inherit from BaseACL.
>>>The data model vinny is proposing seems to me to be generic enough to 
>>>handle any ACL system.  Only thing I am fuzzy on is how you plan on 
>>>tying people to groups and groups to groups?  The same way as 1.3.x does?
>>
>>I was under the impression that the A&A module would handle getting the 
>>user and group info, however and where ever they may be stored.  For 
>>whichever parts I'm wrong on this, current 1.3.x handling of group 
>>membership would be sufficient.  I might add that a well though out set 
>>of access rights would mean we could get rid of about 75% of the 1.3.x 
>>"rights".  The remaining rights (such as story.submit, comment.delete, 
>>etc) could be considered items under ACL control.
>>
>>>
>>>--Tony
>>>
>>--Vinny
>>_______________________________________________
>>geeklog-devel mailing list
>>geeklog-devel at lists.geeklog.net
>>http://lists.geeklog.net/listinfo/geeklog-devel
>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>