Instead of turning on/off strict mode based on the user supplied input,
cast everything to strings and always use a strict check. This avoids
the potential issue of a bad user using hexadecimal when they should not
be allowed to do so. Thanks to 'Kurita Takashi' for pointing this out.
I'm not sure on whether this is a problem with my local app but I have
seen it a couple of times in a couple of projects: Warning (2): Invalid
argument supplied for foreach() [CORE/Cake/Utility/Hash.php, line 52]
I think Hash::get should be able to handle this better rather than
throwing an error in a core Util file.
Refs #3754
This has the benefit that the realpath() method is not applied to a
registered stream wrapper in the constructor of the Folder class.
Using the realpath() method will break the stream.
Thank "davalb" for the original patch.
Historically [prop=1] has matched prop=true as well. This restores that
and also fixes [prop=0] not finding falsey values.
This makes the typing less strict in Hash::extract() but I don't think
it is unreasonable given PHP's type juggling.
Refs #3288
Both `2a` and `2x` are valid types of blowfish hashes, that while being
older should be accepted.
Backport 00c94bd582b83f8b92228b750aea0e8816a4ea89 from 3.x to 2.5.x,
I see this as a bug fix as it fixes incompatibilities with hashes
created by hash_password().
Refs #3575
When using comparison with a boolean, as the filter is a string, we have to convert the data boolean to "boolean string" to avoid type-casting troubles.
## Example
```php
$users = [
[
'id' => 2,
'username' => 'johndoe',
'active' => true
],
[ 'id' => 5,
'username' => 'kevin',
'active' => true
],
[
'id' => 9,
'username' => 'samantha',
'active' => false
],
];
$unactiveUsers = Hash::extract($users, '{n}[active=false]');
print_r($unactiveUsers);
```
This example returns the two unwanted active users because `"false"` is `true` but not `false` :)
I think this pull request will fix this issue by converting true/false boolean to string (to match with our filter).
