[geeklog-devel] For my friend, Vinny

Vincent Furia vfuria at gmail.com
Thu May 29 22:21:02 EDT 2008


I'm not sure at what level you mean about different optimizations.  The
backend should be the same for all the different types.

ACLs for user x, group a (as appropriate)
For the simple blog interface: user x has all rights
For the backwards compatible w/ geeklog 1.x: user x has read or edit, group
a has read or edit
For the "complete ACL": users x, y, z each separately have different access
levels and groups a, b, c each separtely have different levels

No matter the display setting though, the backend database queries and logic
would be the same the for all three methods.  The big advantage here is that
you only need one implementation and you get a lot of flexibility.

-Vinny

On Thu, May 29, 2008 at 6:08 PM, Michael Tutty <michael.tutty at gmail.com>
wrote:

> Vinny,
> 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.
>    M.
>
>
>
>
> 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.
> >
> > -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
> >>
> >>
> >
>
> --
> Sent from Gmail for mobile | mobile.google.com
> _______________________________________________
> 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/e23bab87/attachment.html>


More information about the geeklog-devel mailing list