<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in GroupHierarchyCacheTest.php</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2025</copyright>
    <generator>Java</generator><item>
        <title>e7339d5a8ae85d8bb79a5552d9633163199d0038 - Local handling of nested groups</title>
        <link>http://127.0.0.1:8080/history/plugin/pureldap/_test/GroupHierarchyCacheTest.php#e7339d5a8ae85d8bb79a5552d9633163199d0038</link>
        <description>Local handling of nested groupsAll previous attempts to handle nested groups in a performant matterfailed. Neither recursive requests nor using theLDAP_MATCHING_RULE_IN_CHAIN mechanism were sufficently fast enough to dobulk requests on users.This now takes a completely different approach. When recursive groupsare enabled, a single (paged) request for all groups is done. The listof these groups together with their parent info is then used to resolveany nested group memberships.The group cache is saved in filesystem for the duration of the securitytimeout configuration.Future enhancements should:* see if the cache class could also be used for other caches currently  implemented in Client.php* make the use of filesystem caching configurable

            List of files:
            /plugin/pureldap/_test/GroupHierarchyCacheTest.php</description>
        <pubDate>Thu, 29 Jul 2021 13:44:49 +0000</pubDate>
        <dc:creator>Andreas Gohr &lt;andi@splitbrain.org&gt;</dc:creator>
    </item>
</channel>
</rss>
