- État Fermée
- Pourcentage achevé
- Type Anomalie
- Catégorie Freebox OS → API
-
Assignée à
rfliedel - Système d'exploitation Tous
- Sévérité Haute
- Priorité Très Basse
- Basée sur la version 3.4.1
- Due pour la version Non décidée
-
Échéance
Non décidée
- Votes
- Privée
Ouverte par zakhar - 02/05/2017
Dernière modification par rfliedel - 04/05/2017
FS#21461 - Fonction de Hash buggée depuis la 3.4
La fonction de hash est bugguée depuis la 3.4
L’appel de l’API répond “impossible de parser” le JSON dans 2 cas sur 3. Le cas passant est quand le base64 du nom fini par ==, dans les autres cas on constate le bug.
Voici une trace via mon script qui réalise des md5, j’ai sauté les phases de connexion qui sont “irrelevant” en ce qui concerne ce rapport de bug !
$ for f in a aa aaa aaaa aaaaa aaaaaa; do echo "Fichier: $f"; ~/Scripts/fb5sum.sh "/Disque dur/Téléchargements/$f"; echo; done
Fichier: a
Connexion ... OK
curl -i -s "http://mafreebox.freebox.fr:12345/api/v4/fs/hash/" -H "X-Fbx-App-Auth: ****************************************************************" -d "{"src":"Ii9EaXNxdWVkdXIvVMOpbMOpY2hhcmdlbWVudHMvYSI=","hash_type":"md5"}
{"msg":"Requête invalide : impossible de parser le json","success":false,"error_code":"invalid_request"}
Fichier: aa
Connexion ... OK
curl -i -s "http://mafreebox.freebox.fr:12345/api/v4/fs/hash/" -H "X-Fbx-App-Auth: ****************************************************************" -d "{"src":"Ii9EaXNxdWVkdXIvVMOpbMOpY2hhcmdlbWVudHMvYWEi","hash_type":"md5"}
{"msg":"Requête invalide : impossible de parser le json","success":false,"error_code":"invalid_request"}
Fichier: aaa
Connexion ... OK
curl -i -s "http://mafreebox.freebox.fr:12345/api/v4/fs/hash/" -H "X-Fbx-App-Auth: ****************************************************************" -d "{"src":"Ii9EaXNxdWVkdXIvVMOpbMOpY2hhcmdlbWVudHMvYWFhIg==","hash_type":"md5"}
ba1f2511fc30423bdbb183fe33f3dd0f /Disque dur/Téléchargements/aaa
Fichier: aaaa
Connexion ... OK
curl -i -s "http://mafreebox.freebox.fr:12345/api/v4/fs/hash/" -H "X-Fbx-App-Auth: ****************************************************************" -d "{"src":"Ii9EaXNxdWVkdXIvVMOpbMOpY2hhcmdlbWVudHMvYWFhYSI=","hash_type":"md5"}
{"msg":"Requête invalide : impossible de parser le json","success":false,"error_code":"invalid_request"}
Fichier: aaaaa
Connexion ... OK
curl -i -s "http://mafreebox.freebox.fr:12345/api/v4/fs/hash/" -H "X-Fbx-App-Auth: ****************************************************************" -d "{"src":"Ii9EaXNxdWVkdXIvVMOpbMOpY2hhcmdlbWVudHMvYWFhYWEi","hash_type":"md5"}
{"msg":"Requête invalide : impossible de parser le json","success":false,"error_code":"invalid_request"}
Fichier: aaaaaa
Connexion ... OK
curl -i -s "http://mafreebox.freebox.fr:12345/api/v4/fs/hash/" -H "X-Fbx-App-Auth: ****************************************************************" -d "{"src":"Ii9EaXNxdWVkdXIvVMOpbMOpY2hhcmdlbWVudHMvYWFhYWFhIg==","hash_type":"md5"}
ba1f2511fc30423bdbb183fe33f3dd0f /Disque dur/Téléchargements/aaaaaa
Il s’agit du même programme (puisque lancé dans une boucle shell) or il répond parfois JSON invalide... alors que le JSON est manifestement tout à fait valide !.. et parfois cela fonctionne (prouvant que le JSON est bien valide en réalité !).
Selon l’expérimentation ci-dessus qui montre ce qu’on envoie par curl avec le détail du JSON qui est posté, et montre le retour lorsqu’il y a erreur.
Lorsque cela marche, on obtient le md5 du fichier. En l’occurrence les 6 fichier a à aaaaaa dans /Disque dur/Téléchargement contiennent tous la chaîne “123\n” et ont donc tous un md5 identique.
Pas de contournement de ce bug génant... sauf à changer le nom du fichier à hasher pour que son “base64” finisse par ‘==’ ... assez pénible !
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
bonjour,
je n'arrive pas a reproduire le problème.
Vous pouvez me donner le contenu de votre fb5sum.sh ?
Bien sûr, le script est publié là :
External Link : https://forum.ubuntu-fr.org/viewtopic.php?id=1546061
Il est "propre" c'est à dire qu'il vous faut déclarer une "app" sur la Freebox, et cet "app" doit avoir le droit "filesystem".
Vous pouvez déclarer l'app avec le curl mis en commentaire au début du script.
Il a été fait à l'époque V1 et marchait toujours jusqu'aux API V3 incluses.
Le début du script contient les variables avec le nom que vous avez mis à votre "app".
Une fois ceci recopié chez vous, vous essayez comme je l'ai fait avec des fichiers nommés :
a
aa
aaa
aaaa
aaaaa
aaaaaa
Dans le répertoire /Disque dur/Téléchargements
il manque un -H "Content-Type: application/json" dans les options de curl
Merci, ainsi cela fonctionne !
Je propose donc de remplacer ce rapport de bug par un rapport de bug sur la documentation !
En effet, on trouve 'application/json' 72 fois dans la documentation (je ne les ai évidemment pas comptés à la main... j'ai fait un grep !).
Dans 71 cas ce header est cité dans la réponse. (je n'ai pas compté non plus, j'ai supprimé les application/json suivant de 2 lignes un "Example response" avec un sed... et regardé le résultat).
Le seul endroit où on a une "allusion" qu'il pourrait falloir ce header est donc dans le cas restant qui est cité dans "Adding a new download task" où précisément il ne faut PAS ce header !
Aussi, auparavant la Freebox se fichait d'avoir ou pas ce header, du reste la plupart des autres API s'en fichent aussi (j'ai des scripts pour récupérer des fichiers par exemple qui continuent de fonctionner sans ce header !).
Enfin, c'est tout de même un comportement bizarre du serveur de nécessiter le header 2 fois sur 3 et de fonctionner sans le header la 3ème fois... je vous suggère tout de même de jeter un oeil à ce mystère !..
Résumé : si c'est désormais un header réputé nécessaire dans la requête, ce serait utile le préciser clairement dans la documentation, par exemple dans les changements entre API V3 et API V4 (puisqu'en V3 il ne semblait pas nécessaire).
Pour ce qui est du bug lui-même, le rajout du header réparant le problème, on peut le considéré comme réglé/contourné si vous confirmez la nécessité (au moins pour 2 fois sur 3 !..) de mettre ce header dans les requêtes.
Merci de votre réactivité.
Avec le header:
Note, comme dit plus haut : je n'ai rajouté ce header que sur la soumission du hash.
Il y a plein d'autres endroits du script qui envoient un JSON, comme par exemple la boucle d'affichage de la progression de la tâche, la commande pour récupérer le résultat de la tâche, la commande pour supprimer la tâche de la liste, etc...
Aucune de ces autres commandes ne nécessite le fameux header pour fonctionner !
Je persiste donc, est-ce normal que cette seule commande nécessite le header pour fonctionner... et encore uniquement 2 fois sur 3 puisque lorsque le base64 se termine par '==' le header est bien inutile !
Je persisterais donc à penser qu'il y a bien un bug quelque part... mais qu'effectivement la présence du header permet de le contourner.
... pas sûr que vous ayez un état "contourné" dans le tracker.
P.S.: post sur le forum Ubuntu rajouté pour préciser la modification (à un seul endroit) et le signalement du "comportement bizarre" de cette API si on omet le fameux header.
La doc pourrait être plus claire, mais si le contenu est envoyé en application/x-www-form-urlencoded ça change maintenant la manière dont le contenu de la requête est parsé, en particulier quand le contenu contient un caractère '=' ce qui n'est le cas dans la majorité des appels à l'api.
Le fait que ça fonctionne avec application/x-www-form-urlencoded est une "souplesse" sur laquelle il ne vaut mieux pas se reposer ...