Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inGroup and getUserGroups have different cache keys and implementations #30

Open
PVince81 opened this issue Nov 28, 2016 · 11 comments
Open

Comments

@PVince81
Copy link
Contributor

I'd expect Group_LDAP::inGroup to simply use Group_LDAP::getUserGroups or at least use the same cache keys.

This means that it could happen that the cache contains slightly different values, leading to bugs like owncloud/core#26683 where one API which uses getUserGroups() sees that the user is member of a group, but inGroup says the user isn't.

@jvillafanez @owncloud/ldap

@PVince81
Copy link
Contributor Author

From what I see the cache would be memcache

@PVince81
Copy link
Contributor Author

I tried to force clear partially the cache and found out that inGroup also called _groupMembers which itself stores the same information in yet another cache key "_groupMembers" . $dnGroup

@PVince81
Copy link
Contributor Author

and "inGroup-members" ...

@PVince81
Copy link
Contributor Author

Here are steps to reproduce, it is a bit difficult because it needs a special sharing scenario: owncloud/core#26683 (comment)

It is likely that we can find other easier code path that would trigger inGroup calls.

@PVince81
Copy link
Contributor Author

Also observed on a real env where groupExists would return false but getUserGroups still returns the membership... Broke some stuff with sharing.

@PVince81
Copy link
Contributor Author

We need to rewrite this caching thing to make more sense and only cache a single info once.

@PVince81 PVince81 added this to the 10.0 milestone Dec 23, 2016
@PVince81 PVince81 assigned IljaN and unassigned jvillafanez Jan 18, 2017
@PVince81
Copy link
Contributor Author

@IljaN I'd like you to have a look at this.

You can setup a test LDAP docker using these scripts: https://github.com/owncloud/administration/tree/master/ldap-testing (start.sh then run the zombie spawner scripts).

See inside the scripts for the LDAP credentials.

You'll also need to setup a memcache in ownCloud.
See owncloud/core#26683 (comment) for steps to reproduce.

Let me know if you need more info about the setup, how to setup LDAP or details about this issue.
Thanks!

@IljaN
Copy link
Member

IljaN commented Jan 25, 2017

Postponed until owncloud/core#23558 is done. Memcache usage will be obsoleted by the introduction of the central user+group account table"

@PVince81
Copy link
Contributor Author

Due to the nature of how caching is done here using hashing keys, it is not possible to cache everything only in a single location because we can't look up / search hashed values. (ex: find all groups in which user1 is in)

@PVince81
Copy link
Contributor Author

The user account table is in 10.0 but we'll also need a group table to be able to resolve this.

@PVince81
Copy link
Contributor Author

@jvillafanez is the new adjusted LDAP impl still using memcache for anything ?

@IljaN IljaN removed their assignment Jan 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants