PHP patch release might introduce issue with model insert in edge cases

[sahopp]

Environment:

• LDAP Server Type: OpenLDAP
• PHP Version: 8.3.16 (no issue with earlier versions like 8.3.15)

This is not really a Bug, but something which developers could struggle with debugging for a long time (as I did), and maybe some modifications could help here.

Also, I observed it in a Laravel Environment, but I guess the fixes which could possibly be done should be here in the LdapRecord packages.

Problem

With PHP 8.3.16 and 8.4.3 a check was modified which makes sure that for some ldap operations the array of values is a "numerically indexed array" (see issue php/php-src#17280, pull requests for version 8.4 php/php-src#17284 and 8.3 php/php-src#17287).

Now we have suddenly observed an error when creating a User Model (with $user->save(), which makes a performInsert, and eventually uses ldap_add, see Ldap.php):

ldap_add(): Argument #3 ($entry) must be an array with numeric keys

Analysis

We've observed that the error message is introduced by the check which has been changed in the above pull requests of php-src (php_ldap_is_numerically_indexed_array).

We've checked the $entry variable right before the insert, and all value arrays were indexed arrays.

We later found out that for us as PHP developers, PHP lists (without explicit keys) and associative arrays look the same, while under the hood, they are not, and the new check (php_ldap_is_numerically_indexed_array) only accepts lists.

We then figured out that the problem in our case was that at user creation, we store the User object in the Laravel Session, and later read it from the session again, finalize it and eventually store it. However, apparently due to the serialization of of the object for the session storage, the attribute arrays are probably not seen as lists but associative arrays, which lets the new check for ldap_add fail.

What to do now?

I know this is actually not an issue of ldapRecord but of

1. how PHP handles lists and associative array
2. how we (unwillingly) "convert" the attribute lists to associative arrays when using the Laravel session.

However, maybe it would make sense to catch this before the LDAP operation in ldaprecord, e.g. by something like

$entry = array_map('array_values', $entry);

I could imagine there might be more developers having a similar problem which could be tackled like this. Could also be that there exist other cases where this conversion from list to associative array happens unexpectedly.

We also consider raising an issue for the php-src mentioning that this patch release contained a breaking change (at least in some edge cases), and that it might make sense to revise this check.

[sahopp]

Btw: UPDATE operations should not be affected. In those cases, ldapRecord computes the array of modifications right before the LDAP operation

[stevebauman]

Hey @sahopp, thanks a lot for the detailed report, much appreciated!

Yea we should definitely patch this in LdapRecord itself. I can work on this tonight, or if you want a fix out sooner, submit a PR and I can release it 👍

[stevebauman]

Apologies for the wait on this. v3.7.7 has been released with a patch for this.