This should avoid having to wait for background job to run after
deleting a user in LDAP before being able to delete it in Nextcloud.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
The documentation says it can return false, and even if that is highly
unlikely for sha256, better safe than sorry.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
We cannot set ldap_dn_hash column as notnull because it is empty for
existing users before postSchemaChange is called
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
Adds an ldap_full_dn column to store the dn, and only store a sha256
hash in the ldap_dn which is shorter and can be indexed without
trouble.
Migration still needs to be implemented.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
I did not find any test data that would fail with the previous regex,
but still added data with uppercase to at least test that.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
This avoids having to wait or reset the cache after deleting a user in
the LDAP.
This also fixes a PHP error when running ldap:check-ldap --update on a
deleted but cached user.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
- the issue was present only when using PHP based resolving of nested
group members. Normally nested members are common in AD (and Samba4) and
are resolved per LDAP_MATCHING_RULE_IN_CHAIN by default
- resolving nested members is recursive
- when the cache entry was created it happend for intermediate groups, too,
containing members from the parent group
- the check was added to only cache the root group with its members
- a runtime cache stores intermediate ldap read results
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Using iconv for translit depends upon server configuration, locale, and
PHP version. Using htmlentities instead to have a consistent behavior
independent of configuration.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
* This adds support for the sharing, groupware, theming and user_ldap
app
* This adds some code who disapeared during a rebase in the initial
delegation PR (provisioning_api)
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
- limitation by core tables (e.g. sharing), IDs are always 64chars
- when longer group IDs were requested they are hashed (does not affect
displaynames)
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
- store result when no name could be retrieved, too
- cached value is not an array, was treated wrongly
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
- determine shares may via Sharing code result in user exists checks
- this may result in an infinite loop when user exists was called before
- the info is really only required at one occ command
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
- saves an LDAP requests in these cases
- prevents a Protocol Error logged on < 7.3 API (for backports)
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
