Rendre les sauvegardes de configuration Laravel chiffrées portables sur APP_KEY

En voici une amusante. Vous créez un package qui sauvegarde la configuration d'une application - le.envainsi que les paramètres stockés cryptés dans la base de données — dans un seul ZIP protégé par mot de passe. Tout l'argument de vente est la portabilité : faire une sauvegarde sur le serveur A, la restaurer sur le serveur B, même lorsque les deux serveurs ont des configurations différentes.APP_KEYs. Ensuite, vous écrivez un test qui modifie réellement la clé lors d'une restauration, et il échoue. Les paramètres de la base de données reviennent tronqués.

Il s'avère que le bug ne venait pas du tout du cryptage. C'était dans une cache dont j'avais oublié l'existence. Aujourd'hui, j'ai livré la version 1.1.0 de laravel-config-backup et ce correctif de portabilité faisait la une des journaux. Permettez-moi de le parcourir, car la leçon se généralise bien au-delà de ce paquet.

Pourquoi la portabilité APP_KEY est même une chose

Laravel chiffre les choses avecAPP_KEY. Castings éloquents cryptés, cookies signés, sessions – tout cela détermine cette valeur. Alors si tu es naïvementmysqldumpune table avec des colonnes chiffrées et chargez-la sur un autre serveur, chaque colonne chiffrée est désormais un texte chiffré que la nouvelle clé ne peut pas déchiffrer. Données mortes.

L'astuce utilisée par ce package est de stocker le contenu de l'archive déchiffré. Lorsque j'exporte la base de données, les lignes passent par leurs conversions, de sorte qu'une colonne chiffrée devient une valeur simple à l'intérieur du ZIP (le ZIP lui-même est crypté par mot de passe AES-256, il n'est donc pas en texte brut). Lors de l'importation, ch...
[Courte citation de 8% de l'article original]