Vous voulez instancier une classe qui n’existe pas en PHP ? Hold my beer 🍺.

Un autoloader permet de dicter à PHP comment il doit s’y prendre afin d’instancier une nouvelle classe, en d’autres termes : vous avez le contrôle sur le comportement d’un “new”.

Une fois qu’on s’est dit ca, on peut s’imaginer faire quelques bêtises, par exemple, instancier une classe qui n’existe “pas” réellement.

Imaginez que votre projet possède une unique classe App\Foo et que vous souhaitez l’instancier à partir d’un FQCN quelconque … du genre Domain\Foo ?

Actuellement, cette instanciation lève une erreur, c’est normal, la classe Domain\Foo n’existe pas.

1
2
new Domain\Foo();
# Fatal error: Uncaught Error: Class "Foo" not found

À l’aide d’un autoloader, nous pouvons “attraper” cette instanciation en vol afin de la rediriger ailleurs :

1
2
3
4
5
6
7
8
9
10
spl_autoload_register(function ($class) {

    if (str_starts_with($class, 'Domain')) {

        $alias = str_replace('Domain', 'App', $class);

        return class_alias($alias, $class);
    }

}, true, true);

Ce code sera à placer au plus haut de votre application, dans le cadre de Laravel, dans son fichier bootstrap/app.php.

Grace à cet autoloader, nous instancions désormais la classe Foo présente dans le namespace App/, il n’y a plus d’erreur, le code fonctionne … bien évidemment, évitez d’être contraint d’effectuer ce genre de trick périlleux, mais cela pourrait peut-être vous aider dans des situations très exotiques.

1
2
3
$foo = new Domain\Foo();
var_dump($foo);
# object(Foo)#1 (0) {}

PS : Créer un alias d’une classe inexistante lève un warning en PHP 8, mais entre nous, à ce niveau de magie noire, on s’en moque un petit peu.

Lors d’une migration de base de données un peu barbare il m’est peut-être déjà arrivé un jour de casser la séquence d’un index.

Par exemple, si une table possède 8944 lignes avec une colonne ID (étant une séquence), il est fort à parier que la prochaine valeur de cette colonne soit 8945 … dans ma situation cette valeur était de 241 (?).

En gros, pour la faire courte, la séquence était corrompue.

Pour corriger cette anomalie avant que vos fichiers de logs explosent, on commence par identifier le nom exact de la séquence :

SELECT pg_get_serial_sequence('items', 'id');

Cela nous permet de vérifier avec un nextval la prochaine valeur théorique :

SELECT nextval('public.items_id_seq');

Si cette valeur est effectivement incohérente, nous pouvons la modifier arbitrairement à l’aide d’un setval ;

SELECT setval('public.items_id_seq', 8945);

En Laravel 8, il était malheureusement possible de récupérer une valeur transmise en GET à une URL … à partir de la méthode post d’une instance de request :

// Laravel 8
// http://localhost/?foo=bar

request()->get('foo'); // bar
request()->post('foo'); // bar

Ce comportement, qui apparaît à raison comme une anomalie, a été corrigé en Laravel 9 sans que cette correction soit mentionnée dans le changelog de montée de version. 😐

Désormais, à partir de Laravel 9, le comportement est le suivant :

// Laravel ^9
// http://localhost/?foo=bar

request()->get('foo'); // bar
request()->post('foo'); // NULL

Si par le passé vous avez malencontreusement utilisé la mauvaise méthode sans vous en rendre compte, vous êtes bon pour lancer quelques commandes route:list pour vérifier que vous employez la bonne méthode :

php artisan route:list --method=GET

ps : bon courage si vous avez des routes any

Petite alerte ce matin d’un agent AWS, l’une de nos machines manque d’espace disque.

Si vous voulez passer une mauvaise journée, essayons donc d’attendre que votre serveur atteigne les 100%, vous verrez c’est sympathique de plus pouvoir se connecter en SSH.

Ni une ni deux nous cherchons les dossiers les plus volumineux à l’aide de la commande du :

du -h --max-depth=1 | sort -hr | head -n 10

En étudiant le résultat de la recherche, nous ne sommes rendu compte que le dossier /tmp présent à la racine du serveur faisait plus de 10 GO … soit plus de la moitié des capacités du disque de la machine.

Dans ce dossier, nous nous sommes retrouvés face à une montagne de fichier ayant un pattern similaire : “knp_snappy651be73555b004.69764999.html”.

Après téléchargement, il s’avère que les coupables sont des fichiers temporaires créés par le package laravel-snappy que nous utilisons pour générer des PDF.

Visiblement, dans certaines circonstances, le package n’est pas en mesure de supprimer ses propres fichiers temporaires … ce qui au fil des mois remplira votre serveur de plusieurs GO de fichiers inutiles, jusqu’à l’implosion.

Un rapide coup de suppression à l’aide d’un find :

find /tmp -name "knp_*.html" -type f -delete

Attention à vous, laravel-snappy n’est qu’un wrapper de KnpLabs/snappy qui lui-même encapsule le package wkhtmltopdf, un standard de l’industrie que vous utilisez probablement sans le savoir.

Le problème que nous avons rencontré n’est peut-être pas directement lié à laravel-snappy mais à l’une de ses dépendances, bon courage à vous.

Imaginez que vous devez lancer une commande sur une machine distante nécessitant plusieurs heures d’exécution.

Vous pourriez le faire en vous connectant en SSH sur cette machine et en exécutant votre commande, mais cela vous obligera à conserver votre terminal ouvert … quand bien même ce dernier pourrait être kill pour inactivité ou subir une quelconque coupure.

La commande screen permet de créer et de gérer des sessions de terminal virtuelles détachables sur un système Unix.

On entend par “détachable” qu’il sera possible de créer des sessions permettant de se déconnecter de votre machine tout en laissant les processus en cours d’exécution dans la session, et de s’y reconnecter plus tard.

Une fois connecté en SSH sur votre machine, créé votre session à l’aide de la commande screen -S :

screen -S my_screen_name

Cette commande vous amène directement sur votre session dans laquelle vous pourrez exécuter votre commande.

Une fois que cette dernière sera en cours d’exécution, vous pourrez quitter cette session en tapant sur a puis d tout en maintenant la touche control … c’est un peu technique, mais vous y arriverez.

Une fois à nouveau sur votre machine, toutes les sessions existantes sont affichables avec la commande suivante :

screen -ls

La commande screen -r vous permettra de sauter sur une session existante :

screen -r my_screen_name

Pour finir, un simple exit sur une session vous permettra de la kill.

La configuration de votre serveur MySQL sur Laravel Forge se trouve dans un fichier “my.cnf” :

sudo vim /etc/mysql/my.cnf

Si vous avez perdu votre password sudo d’une machine sur Forge, cherchez dans votre boîte mail un certain “Forge: Server ({name server}) Provisioned”, vous me remercierez plus tard.

Désormais, éditez le fichier my.cnf et modifier la valeur en MO de la clé innodb_buffer_pool_size :

[mysqld]
default_authentication_plugin=mysql_native_password
skip-log-bin
innodb_buffer_pool_size = 400M

La clé innodb_buffer_pool_size est le paramètre de configuration de MySQL qui détermine la quantité de mémoire allouée pour mettre en cache les données et les index, vous améliorez les performances en accélérant les accès aux données fréquemment utilisées.

Après avoir sauvegardé, redémarrer MySQL depuis le panel de configuration de votre serveur sur forge.

Pour finir, vous pouvez lancer cette requête sur votre base de données pour confirmer que la nouvelle valeur est bien prise en compte.

SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; 
// 419430400

La résultat 419430400 est en octets, si vous la convertissez en MO en divisant par (1024 * 1024) vous obtiendrez bien 400MO.

En installant plusieurs versions de PHP sur votre Mac à l’aide de Valet il est possible que Xdebug ne soit pas installé par défault sur tous les binaires de PHP.

La commande suivante affichera les extensions installées sur le binaire de PHP en question, rien ne s’affichera sur le résultat du grep si Xdebug n’est pas installé.

valet php -m | grep xdebug

Pour commencer, il sera necessaire d’identifier le dossier du binaire PHP à qui installer et configurer Xdebug, dans mon cas :

/usr/local/opt/php@8.2

Une fois le dossier identifié, une commande PECL sera nécessaire pour installer le package.

PECL (PHP Extension Community Library) est une bibliothèque pour les extensions PHP écrites en C permettant d’ajouter des fonctionnalités supplémentaires à PHP.

/usr/local/opt/php@8.2/bin/pecl install xdebug

Une fois Xdebug installé à l’aide de PECL, il faudra l’activer dans le php.ini de la version PHP cible :

vim /usr/local/etc/php/8.2/php.ini

Ajoutez l’extension “xdebug.so” à la clé “zend_extension” :

zend_extension="xdebug.so"

Pour finir, vous serez forcé de redémarrer PHP pour activer la nouvelle extension, le plus simple sera tout simplement de restart valet lui-même.

valet restart

Que ce soit pour tester une nouvelle beta ou s’amuser sur une vieille version, voyons comment installer en quelques minutes une version spécifique de php.

How to

Dans mon cas mon environnement de développement sera une simple image docker de debian.

docker run --name playground -it debian

Tout d’abord il est nécessaire d’installer quelques dépendances essentielles à l’installation et au bon fonctionnement de php.

apt-get update && apt-get install build-essential wget pkg-config libxml2-dev vim libsqlite3-dev

Désormais à vous de trouver un lien pour télécharger une release de php, la plupart sont accessibles depuis le site officiel.

À l’heure où j’écris ces lignes la beta en cours (8.1.0 BETA 3) est disponible à cette url.

wget https://downloads.php.net/~ramsey/php-8.1.0beta3.tar.gz

Une fois download, décompressez l’archive de la release.

gunzip php-8.1.0beta3.tar.gz
tar -xf php-8.1.0beta3.tar

Déplacez-vous dans le dossier fraichement créé puis lancez la configuration.

cd php-8.1.0beta3
./configure

Si la configuration s’est correctement effectuée le message “Thank you for using PHP” devrait s’afficher, dans le cas contraire regardez quelques lignes plus haut à la recherche des erreurs.

Il ne reste plus qu’à lancer l’installation qui vous laissera le temps de vous faire un ou deux cafés.

make && make install

C’est terminé, la commande suivante doit dés lors afficher la bonne version de php.

php -v // PHP 8.1.0beta3 (cli)

Have fun !

Lors d’une soirée live coding sur la chaine twitch DevMaker_tv nous nous sommes intéressés à une subtilité de Laravel présente dans le fichier UserFactory.

1
2
3
4
5
6
7
8
9
10
public function definition()
{
    return [
        'name' => $this->faker->name,
        'email' => $this->faker->unique()->safeEmail,
        'email_verified_at' => now(),
        'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password

        'remember_token' => Str::random(10),
    ];
}

Comment est-ce possible que le hash du champ password soit hardcodé dans notre UserFactory alors que la valeur d’environnement APP_KEY de l’application n’est pas encore définie ?

J’ai toujours bêtement consideré que APP_KEY était utilisé comme salt pour tous les hash, pour autant, lors d’une nouvelle installation de Laravel la valeur de APP_KEY… est null.

Et puis entre nous, un salt statique commun à toutes les nouvelles applications… C’est sacrement naze comme idée.

Creusons dans le code pour comprendre le fin mot de l’histoire.

TL;DR

Le APP_KEY est uniquement utilisé pour l’encryption.

Un password en base de données est quant à lui hashé par un password_hash avec bcrypt comme algorithme par défaut.

Cet hash de password est hardcodé pour des questions d’optimisation, un password_hash étant fortement demandeur en ressources.

Exploration

Premières constatations, il n’y a rien de natif dans Laravel pour hash automatiquement l’attribut password d’un model User lors de son insertion.

C’est aux développeurs de gérer ce besoin… et la documentation n’est pas forcément très loquace sur la marche à suivre.

On apprend depuis la documentation que la méthode Auth::attempt(), permettant d’authentifier un utilisateur, procedera à un hash du password submit pour le comparer avec celui présent en base de données.

The attempt method accepts an array of key / value pairs as its first argument. The values in the array will be used to find the user in your database table. If the user is found, the hashed password stored in the database will be compared with the password value passed to the method via the array.

Pour comprendre ce qui se passe, nous allons retracer le code utilisé lors d’une tentative d’authentification pour déterminer comment Laravel hash un password.

Comprendre l’authentification

Une tentative d’authentification fonctionne deux temps :

• Récupérer un utilisateur.
• Vérifier que le password envoyé est correct.

Le workflow d’authentification de Laravel est complexe et totalement configurable, la récupération d’un utilisateur et l’objet que retournera l’authentification sont dissociés.

Par défaut, la récupération de l’utilisateur se trouve dans la class EloquentUserProvider et l’objet retourné est un model User.

Ce choix est configurable dans le fichier config\auth.php.

1
2
3
4
5
'providers' => [
    'users' => [
        'driver' => 'eloquent', // EloquentUserProvider 

        'model' => App\Models\User::class,
    ],

Lors d’une tentative d’authentification, apres avoir récupéré l’utilisateur depuis la méthode retrieveByCredentials du EloquentUserProvider, c’est au rôle de la méthode validateCredentials de vérifier la concordance du password à l’aide d’un objet hasher.

1
2
3
4
5
6
public function validateCredentials(UserContract $user, array $credentials)
{
    $plain = $credentials['password'];

    return $this->hasher->check($plain, $user->getAuthPassword());
}

Après vérification, il s’avère que cette variable hasher est une instance de BcryptHasher, que Laravel génère depuis un design pattern Manager.

C’est ce BcryptHasher qui aura la charge de vérifier le pertinence du password.

Le check du password

Nous y sommes, voici comment Laravel hash un password lors d’une tentative d’authentification.

1
2
3
4
5
6
7
8
public function check($value, $hashedValue, array $options = [])
{
    if (strlen($hashedValue) === 0) {
        return false;
    }

    return password_verify($value, $hashedValue);
}

Le framework utilise une fonction password_verify native à php… et notre APP_KEY n’intervient à aucun moment en tant que salt.

On peut donc affirmer que la valeur du APP_KEY n’impacte pas le hash des passwords.

Alors à quoi il sert ?

Hasher n’est pas crypter

Le APP_KEY est uniquement utilisé en tant que salt pour crypter des informations depuis la class Crypt.

Les passwords des utilisateurs sont quant à eux hashé à l’aide d’un algorithme que vous pouvez configuer dans config\hashing.php.

C’est pour cette raison que UserFactory contient un hash hardcodé, $2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi correspondra toujours à la valeur password.

Bisous, bonne journée.

Nous sommes parfois amenés à vouloir manipuler une propriété ou une méthode protected de nos class.

L’utilisation de la reflection est envisageable pour modifier la visibilité mais une autre solution élégante à base de closure est également possible.

Considérons la class suivante :

1
2
3
4
class Foo {
    protected $bar;
    protected function bar() {}
}

L’idée est d’utiliser le Closure::call introduit en php7 pour injecter une closure dans le scope d’une instance de la class Foo.

1
2
3
4
5
6
7
8
$foo = new Foo();

$closure = function () {
    $this->bar = false;
    $this->bar();
};

$closure->call($foo);

Une fois notre closure injecté, il lui est désormais possible d’acceder à toutes les proprietés et méthodes protected de notre class.

Certes, c’est pas usuel, mais vous êtes majeur et vacciné.