Re: [RFC] [Discussion] array_get and array_has functions

On Sun, Apr 5, 2026, at 11:34, Barel wrote: > On Sun, 5 Apr 2026 at 08:54, Rob Landers <rob@bottled.codes> wrote: >> __ >> On Sat, Apr 4, 2026, at 16:06, Barel wrote: >>> Hi, >>> >>> I would like to open the discussion on my proposal to add two small, focused array >>> functions for retrieving and checking nested array elements using dot notation. >>> >>> This is the link to the RFC: >>> https://wiki.php.net/rfc/array_get_and_array_has >>> >>> This is the link to the proposed implementation: >>> https://github.com/php/php-src/pull/21637 >>> >>> Thanks!! >>> >>> Carlos >> >> Hi Barel, >> >> Interesting! As dot-notation isn't used anywhere else, and I don't see it >> discussed as part of the RFC, how are developers to prevent injections of dots in user input? With >> SQL, we have parameters and escaping ... but I don't see any of that here. >> >> As an example: >> >> $user = [ 'data' => [...], 'password' => 'secret' ]; >> >> If the path is completely user-controlled (as in the examples given), then they can access >> sensitive information in the array. Even if it is prefixed, ie., "data.%s" -- an attacker >> can simply enumerate all possible keys and subkeys. >> >> As it stands, it appears to add a new vulnerability to PHP that will be unfamiliar with PHP >> developers -- unless they're using a framework that already does this sort of notation. >> >> — Rob > > Thanks Rob. Probably user input is not the best use case for these functions, I just used it in > the examples because it is simple. And quite dangerous. I’d recommend using realistic examples that showcase the work instead of simple examples that scream “hack me” to anyone who’s written PHP more than a few years. > In any case, if your program allows unrestricted array access using a user defined path, the > vulnerability already exists, these functions just make it easier to implement the access. That’s the rub, right? Array access simply cannot have a user-defined array path today. This feature allows that but as of this reply, the RFC does not disclose the danger of such a thing despite using it in the examples. It’s either irresponsible or naïve. > If you did not have them and wanted the same functionality you would use a custom > implementation (like the one provided by Laravel) and you would have the same vulnerability > > Cheers > > Carlos Different frameworks and implementations assign different semantics. I’ve seen dots (such as in laravel), slashes, double back-slashes, etc. over the years. I think dots is a fine choice, but it is worth pointing out that, currently, array keys are binary-safe. These simple looking functions completely ignore that. Even if you escape the dots, now you have two variables: $escaped_key (for use in these functions) and $unescaped_key. I see that wildcards are also being considered in the future. Maybe, instead of adding two thin utility functions to global space, it would be better to create an QueryableArray class … kinda like Linq in C# … to handle this type of stuff? Otherwise, this becomes a slippery slope of assigning semantics to random byte sequences. If you’re going to add query semantics to arrays, do it properly.. — Rob