[geeklog-devel] Circular group references
vmf at abtech.org
Mon May 19 11:33:51 EDT 2003
The changes I made to lib-security removed the recursive functions calls
that really slowed down the process of looing up group membership. The
iterative process of group membership look up is pretty fast. This
combined with the fact you'd have to merge these caches for people with
multiple group memberships and I don't think you'll see a significant
speed up in most cases. While not necessarily difficult, keeping a
cache updated correctly in the database could introduce some
difficulties (would you have to regenerate the cache for every group
when you delete a single group, etc).
Tony Bibbs wrote:
> Here is a unique suggestion related to all this.
> Group-level security changes shouldn't happen all that often. Given that,
> when changes are made to a group we should loop through all groups and
> build their membership in a cache field. Then you get out of the business
> of expensive recursive calls on each page request.
> Did that make sense? Does it sound feasible?
> On Sat, 17 May 2003,
> Vincent Furia wrote:
>>Dirk Haun wrote:
>>>Here's an interesting case I had:
>>>Someone wasn't able to log into his site any more. Geeklog went from
>>>index.php to users.php and then seemed to sit there forever.
>>>As it turned out, he had set up a circular group reference, i.e. group A
>>>was assigned to group B and group B to group A. So when someone who was
>>>in one of those groups tried to log in, Geeklog went into an endless loop.
>>>The funny thing is that using Vincent's speed improvements in lib-
>>>security.php enables you to log into such a site nonetheless. So
>>>replacing lib-security.php with the version from CVS is one way to
>>>resolve these problems.
>>In case anyone is curious, the reason my speed improvement doesn't get
>>caught in this loops is because as it creates the list of membership
>>groups, it checks to see if a group has already been added to the list
>>of groups, and if so, ignores it.
>>I don't think there is any reason we necessarily need to restrict
>>circular group assignments, besides geeklog-1.3.7's logon problems
>>(which will be fixed in the next release by my lib-security speed
>>improvements) it really doesn't hurt anything.
>>>However, Geeklog shouldn't let you set up such dependencies in the first
>>>place. Avoiding that, though, seems to be an interesting challenge ...
>>geeklog-devel mailing list
>>geeklog-devel at lists.geeklog.net
More information about the geeklog-devel