- enlarging string cols from 255 to more than 4000 fails on default
Oracle installations for invalid datatype conversion
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Using password_hash is expensive and should be used for hashing
passwords when saving them in the database. Here we just want to see if
the bind was already done with the given password, so use a fast hashing
algorythm.
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
Had to set at least one var when creating an empty configuration in
order to save the default values.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
- as used in LDAP's AbstractMapping::clear() method
- and in Comment's ManagerTest::setUp()
- fixes a DB Exception with Oracle
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
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>
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>
Generators cannot be iterated with while or returned by an other
generator, using foreach instead.
And a few other problems.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
- in a proper setup there are no duplicated UUIDs
- not all setups are proper
- log warning to admin
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Use a backup table to copy the data, drop table and recreate it with
correct primary key, then copy the data back and drop the backup table.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
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>
Co-authored-by: MichaIng <micha@dietpi.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>
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>
