Tweet
Bonjour à tous,
Ce matin, j'ai été confronté à un problème avec LazyDbBackup, soumis par un utilisateur : lorsqu'il demandait le cryptage du dump, le mail arrivait sans pièce jointe.
Ce qui a été appelé "cryptage" est en fait une compression zip du fichier de sauvegarde (sql ou sql.gz) avec mot de passe défini dans la gestion du plugin.
Cette fonctionnalité existe depuis la version originale de Stefan Granholm, et je ne m'y étais pas vraiment intéressé.
Après investigations (un autre site sur le même VPS ne comportait pas d'erreur à ce niveau), il s'est avéré que la cause était la présence d'une apostrophe dans le mot de passe, provoquant une erreur lors de la compression zip.
La ligne de code lançant cette compression est ($zipcmd est "zip" pour un serveur non Windows) :
Je viens de tester sur mon serveur les caractères ' (apostrophe simple) et " (apostrophe double) : le premier empêche la compression, le second pas.
Avec les slashes et antislashes, le premier empêche la compression, le second la permet, mais lorsque j'essaie de dézipper avec WinZip, l'antislash n'est pas reconnu dans le mot de passe saisi et donc le mot de passe en question refusé.
De même, un caractère accentué est refusé à la décompression.
Je n'ai pas trouvé dans la doc PHP d'infos sur l'usage des mots de passe et leurs restrictions avec "zip", mais peut-être ai-je mal cherché ?
WinZip met une alerte sur la nécessité de n'utiliser que des caractères A-Z de l'alphabet latin, des chiffres et des signes de ponctuation standard. Quid avec d'autres alphabets ? Faut-il interdire ce cryptage aux grecs, russes, asiatiques... ?
Y a-t-il d'autres solutions (traitement du mot de passe ?) que déconseiller ces caractères accentués et spéciaux et/ou de tester systématiquement la compression suivie de décompression pour s'assurer qu'on dispose bien d'une archive utilisable ?
Merci par avance de vos conseils !
Robert
Ce matin, j'ai été confronté à un problème avec LazyDbBackup, soumis par un utilisateur : lorsqu'il demandait le cryptage du dump, le mail arrivait sans pièce jointe.
Ce qui a été appelé "cryptage" est en fait une compression zip du fichier de sauvegarde (sql ou sql.gz) avec mot de passe défini dans la gestion du plugin.
Cette fonctionnalité existe depuis la version originale de Stefan Granholm, et je ne m'y étais pas vraiment intéressé.
Après investigations (un autre site sur le même VPS ne comportait pas d'erreur à ce niveau), il s'est avéré que la cause était la présence d'une apostrophe dans le mot de passe, provoquant une erreur lors de la compression zip.
La ligne de code lançant cette compression est ($zipcmd est "zip" pour un serveur non Windows) :
Code PHP:
exec("$zipcmd -j -P $password "$backupfile.zip" "$backupfile"");
Avec les slashes et antislashes, le premier empêche la compression, le second la permet, mais lorsque j'essaie de dézipper avec WinZip, l'antislash n'est pas reconnu dans le mot de passe saisi et donc le mot de passe en question refusé.
De même, un caractère accentué est refusé à la décompression.
Je n'ai pas trouvé dans la doc PHP d'infos sur l'usage des mots de passe et leurs restrictions avec "zip", mais peut-être ai-je mal cherché ?
WinZip met une alerte sur la nécessité de n'utiliser que des caractères A-Z de l'alphabet latin, des chiffres et des signes de ponctuation standard. Quid avec d'autres alphabets ? Faut-il interdire ce cryptage aux grecs, russes, asiatiques... ?
Y a-t-il d'autres solutions (traitement du mot de passe ?) que déconseiller ces caractères accentués et spéciaux et/ou de tester systématiquement la compression suivie de décompression pour s'assurer qu'on dispose bien d'une archive utilisable ?
Merci par avance de vos conseils !
Robert
