#1612 Shared folder cache not updated when syncing groups to LDAP

v5.x
open
nobody
1
2014-10-15
2014-05-18
Pieter
No

I've had an issue which is probably quite rare, because it is predicated on several circumstances.

My setup:
- Two VPSs, one runs Group-Office, the other runs an LDAP directory that contains users and groups. Most users from LDAP do not have access to Group-Office.
- Group-Office authenticates users directly against LDAP, but groups are synced.
- The groups in LDAP are meant to define the groups in Group-Office. The Group-Office VPS runs a cronjob [1] every minute to sync the groups between the two VPSs.
- Every group in LDAP has a corresponding folder in Group-Office that is shared by the admin user, and to which this group has read & write permissions.

[1] As per https://www.group-office.com/wiki/Synchronize_LDAP_users, the cronjob is called with

$ /usr/share/groupoffice/groupofficecli.php -r=ldapauth/sync/groups --delete=1 --max_delete_percentage=25 2>&1 > /dev/null

What I do:
- I add a user to a group in LDAP

What happens:
- The group membership of the user is synced to Group-Office.
- When the user logs in, he doesn't see the Shared folders to which his new group allows him access. However, in the group listing, he does show up as a member of the new group.

What I expect:
- The group membership of the user is synced to Group-Office.
- When the user logs in, he sees the Shared folders to which his new group allows him access.

I've looked into this quite extensively, and I found out that what goes wrong is the following:
- The list of Shared folders is calculated when the user logs in and cached (the function rebuildCache in /modules/files/model/SharedRootFolder.php). This calculation only happens if the folders have been modified.
- However, our use of synchronisation leads to another scenario in which we would like to clear the cache: whenever the group memberships of a user have changed due to the synchronisation. This currently does not happen.

Suggested fix: (for which I lack the knowledge of Group-Office)
- Whenever group membership of a user changes during LDAP synchronisation of groups (and possibly users?), set the 'files_shared_cache_ctime' setting for that user in the go_settings table to 0. This will clear the cache the next time he logs in.

Workaround: (for mere mortals such as I)
- Set a MySQL event right after the synchronisation of groups that sets the 'files_shared_cache_ctime' setting for all users to 0. This involves turning on the event scheduler in MySQL [2] and creating an event such as:

> CREATE EVENT `groupoffice-clear-cache-after-sync`
    ON SCHEDULE EVERY 1 DAY
    DO UPDATE go_settings SET value = 0 WHERE name = 'files_shared_cache_ctime';

[2] https://dev.mysql.com/doc/refman/5.1/en/events.html

Discussion