[geeklog-devel] For my friend, Vinny

[Vincent Furia]

The reason why I suggested ACLs when we started working on GL2 was
flexibility.  It is basically just a GUI change to present 1, 2 or 3 to the
user.  The backend can be exactly the same for all 3.  I imagine it would be
pretty easy to make a configuration option that was.

Choose access level control:
1. One site user, no complex ACLs
2. Legacy Geeklog 1.x
3. Full ACL support

And then adjust the GUI based on that choice.  Obviously you'd have to come
up with better descriptions than those I made on the fly above.

-Vinny

On Thu, May 29, 2008 at 4:25 PM, Tony Bibbs <tony at tonybibbs.com> wrote:

> Yeah, that's pretty much where I was going with it.  We've been talking
> about this pretty much all day and we think while this complexity is nice we
> need to consider using three basic levels of security checking:
>
> 1) Blog: Single user blogging about their own stuff.  They never intend to
> have their site act in any other capacity so no need to complicate the use
> of ACLs.
> 2) Community: This would essentially work just like 1.x
> 3) Enterprise: This would come with a full set of ACLs checks per our
> current discussion.
>
> I'm not sure about the need for both 2 and 3 but I do feel strongly about
> needing #1.  In fact Michael suggested that during the install we should ask
> how they intend to use the software to help them pick the right path.
>
> Thoughts?
>
> --Tony
>
>
> ----- Original Message ----
> From: Vincent Furia <vfuria at gmail.com>
> To: Geeklog Development <geeklog-devel at lists.geeklog.net>
> Sent: Thursday, May 29, 2008 5:17:01 PM
> Subject: Re: [geeklog-devel] For my friend, Vinny
>
> Like in GL 1.4.x, you'd have to resolve the total set of group membership
> before doing the query.  Since you're caching credentials anyway, you could
> cache the total group membership as well.  So, in your example, a user in
> group 3 would have a total group membership of 3, B, 2, 1, A.  The the query
> would check for rights for all those groups, and "and" the results together
> (getting the highest level of access granted to those groups).
>
> There a couple of levels where we can cache this data.  It probably makes
> sense to keep it denormalized in the user table or the group table and
> update all users when a group memberships are modified.  It can also be
> cached in the session, but then you run the risk of updating groups
> membership not being recognized until the session expires.
>
> Let me know if additional/better explanation is needed.  I'm not sure I did
> all that good a job of describing what I meant.
>
> -Vinny
>
> On Thu, May 29, 2008 at 2:57 PM, Tony Bibbs <tony at tonybibbs.com> wrote:
>
>> Lol, so we are getting serious for the GL2 alpha and the ACL stuff is
>> mostly done minus one real PITA.  For reference there's been this page:
>>
>> http://wiki.geeklog.net/wiki/index.php/Using_ACLsG2
>>
>> So we've done some incarnation of everything there minus the last section
>> called:
>>
>> "Selecting Multiple Items Based on Permissions"
>>
>> Any chance you have the "how" part of that?  My brain is hurting.  Why:
>>
>> Groups can be tied in a complex web (not necessarily hierarchical).  For
>> example
>>
>> Group B belongs to Group A
>> Group C belongs to Group B
>> Group 2 belongs to Group 1
>> Group 3 belongs to Group 2
>> Group 3 belongs to Group B
>>
>> That's a worst case scenario but me-thinks it'd be awful hard to do in
>> SQL.
>>
>> --Tony
>>
>>
>> _______________________________________________
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
>> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>>
>
>
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20080529/625bdf12/attachment.html>