[geeklog-devel] For my friend, Vinny
michael.tutty at gmail.com
Thu May 29 20:08:15 EDT 2008
While you're right that the GUI could be different, there are also
different optimizations at the different levels. I suggested that we
get the "blog" ACL module working, since relatively slow code won't
matter there. Then as we move to the more complex models, we can
either keep the simpler code as-is, or make the more robust module
handle the lower-level stuff.
On 5/29/08, Vincent Furia <vfuria at gmail.com> wrote:
> 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.
> 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
>> 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
>> how they intend to use the software to help them pick the right path.
>> ----- 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
>> 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
>> would check for rights for all those groups, and "and" the results
>> (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
>> all that good a job of describing what I meant.
>> 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:
>>> So we've done some incarnation of everything there minus the last section
>>> "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
>>> 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
>>> geeklog-devel mailing list
>>> geeklog-devel at lists.geeklog.net
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
Sent from Gmail for mobile | mobile.google.com
More information about the geeklog-devel