Original Description

      We've recently decided to clean up our permission scheme a bit, and part of this involved using nested groups. We already used Crowd to link our Confluence instance (as well as JIRA and some third-party things) to our Active Directory server, and Crowd supports nested groups so we didn't think there would be any problem.

      Since then however, it happens regularly that users can't access a certain space in Confluence to which they should have access through nested groups. For example, there would be a space called "Human Resources", to which a group called "confluence-hr" has full access. Then there would be a group "Management" that is a member of the "confluence-hr" group amongst others, and obviously the management people are members of this group. The goal is to be able to add people to just one or two "role" groups like "Management" by which they get all the permissions they need, while also being able to keep fine-grained control, so that if someone needs just access to the HR space, we add them to the confluence-hr group and they don't get access to everything else like Management.

      The only fix I've been able to find is restarting the Confluence instance. After a restart, everything works fine again, but a bit later the same problem arises. This happens sometimes several times a day, and it's very irritating. Can anyone suggest a proper fix for this, or is this a genuine bug?

      Updated Description

      This is caused by CWD-1996.

      Workaround

      We have still not been able to find the source of the problem within the confluence code, however we do know that someone the confluence caches are affecting the crowd caches.

      We have attached the crowd-integration-client-2.0.7-CWD-1996.jar which shades net.sf.ehcache to com.atlassian.crowd.shaded.ehcache. What this means is that there is no possible way that Confluence could have any effect whatsoever with the Crowd integration client's caches. They are essentially different classes that Confluence knows nothing about.

      To apply the patch, upgrade to crowd 2.0.7 and in your confluence instance, remove the any other Crowd integration client JARs from
      CONFLUENCE_INSTALL/confluence/WEB-INF/lib
      and place the attached crowd-integration-client-2.0.7-CWD-1996.jar and restart confluence.

      This integration is being completely rewritten for Crowd 2.1 / Confluence 3.5, which will fix this bug permantently.

            [CONFSERVER-19431] Crowd+Confluence nested groups fail

            Hi Matt, 

            I am facing similar problem in ticket. My nested group is not effective after  confluence service is restarted. 

            This is my situation: 

            We have group School_A .  We also have group Class_B inside group School_A. In group Class_B, we create some users (user1, user2, user3).  We create groups and users by Crowd

            When Confluence server reboot or confluence service is restarted, I go to Confluence administrator page, -->go to Group in Users and Security directories, I do a search on School_A or Class_B, I don't see users in those group.

            I have to go to User Directories and press Synchronize==> users will be shown back in groups of confluence

            My crowd version is 3.7.1. My Confluence version is 7.2.0

            Can you help me talk a look on it? 

             

            Thanks, 

            Navy

             

             

             

             

            phuong nghia le pham added a comment - Hi Matt,  I am facing similar problem in ticket. My nested group is not effective after  confluence service is restarted.  This is my situation:  We have group School_A .  We also have group Class_B inside group School_A. In group Class_B, we create some users (user1, user2, user3).  We create groups and users by Crowd When Confluence server reboot or confluence service is restarted, I go to Confluence administrator page, -->go to Group in Users and Security directories, I do a search on School_A or Class_B, I don't see users in those group. I have to go to User Directories and press Synchronize==> users will be shown back in groups of confluence My crowd version is 3.7.1. My Confluence version is 7.2.0 Can you help me talk a look on it?    Thanks,  Navy        

            Matt Ryall added a comment -

            This issue is resolved in Confluence 3.5. The broken Crowd integration client that caused this problem is no longer used in Confluence.

            Matt Ryall added a comment - This issue is resolved in Confluence 3.5. The broken Crowd integration client that caused this problem is no longer used in Confluence.

            Partha added a comment -

            Dear Jeff,

            Thanks for sharing those details!

            I will ask a developer to have a look at your patch.

            Kind Regards,
            Partha Kamal

            Partha added a comment - Dear Jeff, Thanks for sharing those details! I will ask a developer to have a look at your patch. Kind Regards, Partha Kamal

            Jeff Kirby added a comment - - edited

            This problem was common on our Confluence 3.0.2 and rampant after upgrading to Confluence 3.3.1. In September we tried a patch that Atlassian provided. It improved the 3.3.1 bug so that the occurrence lowered from several times an hour to a few times a week, to the 3.0.2 level. In the mean time we investigated the source ourselves as we were able to reproduce the problem on a test server.

            I believe that yesterday we've finally come up with a version that eliminates nested group failure bug! yay! I've posted the patch to CSP-51344 so that Atlassian engineers can look at it.

            There are several problems

            1. NestingHelper uses the crowd integration caches as data structures to pass data between its private members. This is error prone as the cache is highly mutable. Instead use method-scoped maps.
            2. When one item in a crowd integration cache expires, then because of the inter-relationships of nested groups, all the crowd integration caches need to be cleared and rebuilt and all reads or writes to the cache must be blocked until the rebuild finishes.

            Jeff Kirby added a comment - - edited This problem was common on our Confluence 3.0.2 and rampant after upgrading to Confluence 3.3.1. In September we tried a patch that Atlassian provided. It improved the 3.3.1 bug so that the occurrence lowered from several times an hour to a few times a week, to the 3.0.2 level. In the mean time we investigated the source ourselves as we were able to reproduce the problem on a test server. I believe that yesterday we've finally come up with a version that eliminates nested group failure bug! yay! I've posted the patch to CSP-51344 so that Atlassian engineers can look at it. There are several problems NestingHelper uses the crowd integration caches as data structures to pass data between its private members. This is error prone as the cache is highly mutable. Instead use method-scoped maps. When one item in a crowd integration cache expires, then because of the inter-relationships of nested groups, all the crowd integration caches need to be cleared and rebuilt and all reads or writes to the cache must be blocked until the rebuild finishes.

            Any progress here? Is rebooting periodically the only workaround?

            Kurt Reiner added a comment - Any progress here? Is rebooting periodically the only workaround?

            I checked with the James and Matt and sharing the CacheManager is by design - although overwriting Confluence's cache setting is not.

            Stefan Saasen (Inactive) added a comment - I checked with the James and Matt and sharing the CacheManager is by design - although overwriting Confluence's cache setting is not.

            I've looked into this issue while trying to fix our currently failing Confluence-Crowd build.

            I think this problem occurs due to the fact that both Confluence and the Crowd integration client use the static factory methods on net.sf.ehcache.CacheManager. These will create a singleton instance of the CacheManager that is then shared between Confluence and the Crowd client. As a side effect only one cache configuration will actually be used and at lease for our build it seems to be the crowd one. E.g. the cache definition for one of our caches defines a value of 5000 for maxElementsInMemory and FIFO as the eviction policy but debugging the caches in the Confluence-Crowd instance shows that this cache is using the default size (1000) and eviction policy (LRU) - this should not happen.

            Another side effect is that flushing the caches from the Confluence UI now affects both the Crowd client and Confluence caches.

            Stefan Saasen (Inactive) added a comment - - edited I've looked into this issue while trying to fix our currently failing Confluence-Crowd build. I think this problem occurs due to the fact that both Confluence and the Crowd integration client use the static factory methods on net.sf.ehcache.CacheManager . These will create a singleton instance of the CacheManager that is then shared between Confluence and the Crowd client. As a side effect only one cache configuration will actually be used and at lease for our build it seems to be the crowd one. E.g. the cache definition for one of our caches defines a value of 5000 for maxElementsInMemory and FIFO as the eviction policy but debugging the caches in the Confluence-Crowd instance shows that this cache is using the default size (1000) and eviction policy (LRU) - this should not happen. Another side effect is that flushing the caches from the Confluence UI now affects both the Crowd client and Confluence caches.

            Redoing link to reflect correct relationship.

            David O'Flynn [Atlassian] added a comment - Redoing link to reflect correct relationship.

            shihab added a comment -

            This issue, which is said to be caused by CWD-1996, may not be a Crowd bug but rather a Confluence bug.

            Customers have pointed both JIRA and Confluence to Crowd 2.0.x and have had no issues with nested groups in JIRA. The exact same cache code in the Crowd client libraries are used by both JIRA and Confluence.

            This problem seems to have been introduced in Confluence, many users have reported this issue to appear after an upgrade to Confluence 3.2.

            It may be that the Crowd caches (implemented via EhCache) are being modified in some way by Confluence as the caches are losing information. I doubt Confluence is explicitly deleting entries but it may be possible that Confluence/customers are resizing or flushing caches? One way to investigate this further would be to examine the interaction between Confluence and EhCache, in particular, where Confluence attempts to manage non-Confluence caches.

            shihab added a comment - This issue, which is said to be caused by CWD-1996 , may not be a Crowd bug but rather a Confluence bug. Customers have pointed both JIRA and Confluence to Crowd 2.0.x and have had no issues with nested groups in JIRA. The exact same cache code in the Crowd client libraries are used by both JIRA and Confluence. This problem seems to have been introduced in Confluence, many users have reported this issue to appear after an upgrade to Confluence 3.2. It may be that the Crowd caches (implemented via EhCache) are being modified in some way by Confluence as the caches are losing information. I doubt Confluence is explicitly deleting entries but it may be possible that Confluence/customers are resizing or flushing caches? One way to investigate this further would be to examine the interaction between Confluence and EhCache, in particular, where Confluence attempts to manage non-Confluence caches.

            Adon Metcalfe added a comment - - edited

            Reproduced for us with crowd also. Temporarily working around by adding each nested group to confluence permissions =/, we are running version 3.3 of confluence and crowd 2.0.6

            Adon Metcalfe added a comment - - edited Reproduced for us with crowd also. Temporarily working around by adding each nested group to confluence permissions =/, we are running version 3.3 of confluence and crowd 2.0.6

              matt@atlassian.com Matt Ryall
              602f55ce-b5a5-4156-b296-86f3daf0eed9 Deleted Account (Inactive)
              Affected customers:
              14 This affects my team
              Watchers:
              20 Start watching this issue

                Created:
                Updated:
                Resolved: