[geeklog-devel] ACL follow-up

[Tony Bibbs]

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