Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

  • État Confirmé
  • Pourcentage achevé
    0%
  • Type Anomalie
  • Catégorie Freebox OS → API
  • Assignée à Personne
  • Système d'exploitation Freebox Server V7 (Delta)
  • Sévérité Basse
  • Priorité Très Basse
  • Basée sur la version 4.9.0
  • Due pour la version Non décidée
  • Échéance Non décidée
  • Votes
  • Privée
Concerne le projet: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
Ouverte par nbanba - 23/03/2025
Dernière modification par nbanba - 24/03/2025

FS#40140 - Cas où l'API du player DEVIALET ne renvoit pas du JSON

Bonjour

Il existe au moins 1 cas à priori non documenté ou l’API du player Devialet ne renvoit pas du JSON

Si je fais la requête pour reboot mon player en utilisant le bon ID pour mon player, la réponse est en JSON ⇒ OK

Si je fais volontairement une requête sur un mauvais ID de player, le player renvoit du HTML au lieu de renvoyer du JSON :

Exemple:
La fonction reboot player prend en argument l’ID du player (mon player à pour ID 17)

Si je fais:

reboot_player 17


J’obtiens le JSON:

{"success":true}

Maintenant si je passe un ID erroné volontairement(ex: ID 0), l’API ne renvoi pas une erreur en JSON mais du HTML:
Trace debug:

$ debug=1
$ reboot_player  0
get_fbx_api request:
curl -s https://mafreebox.freebox.fr/api/v14/player -H "Content-Type: application/json" -H "X-Fbx-App-Auth: $_SESSION_TOKEN" -G --cacert /dev/shm/fbx-cacert 

get_fbx_api result:
{"success":true,"result":[{"mac":"34:27:92:80:29:7c","stb_type":"stb_v7","id":17,"last_time_reachable":1742725668,"api_available":true,"device_name":"Freebox Player","device_model":"fbx7hd-delta","reachable":true,"uid":"a51dde83e07a057e64bef5bdcac8c5e2","api_version":"14.0","lan_gids":["ether-34:27:92:80:29:7c"]}]}

post_fbx_api request:
curl -s "https://mafreebox.freebox.fr/api/v14/player/0/api/v14/system/reboot" -H "Content-Type: application/json" -H "X-Fbx-App-Auth: $_SESSION_TOKEN" -X POST --cacert /dev/shm/fbx-cacert -d {}

post_fbx_api result:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Freebox :: Requête invalide</title>
<link href="/err/err.css" rel="stylesheet" type="text/css" />
</head>

<body>
<div id="info">
    <div id="errorMsg">
      <h3>Requête invalide</h3>
      <p class="desc">La requête envoyée est invalide</p>
    </div>
</div>

</body>
</html>

Je comprend bien que c’est du à l’URL qui devient “mauvaise” car l’ID du player est incluse dans l’URL

cette URL n’existe en fait pas:
https://mafreebox.freebox.fr/api/v14/player/0/api/v14/system/reboot

par contre celle-ci existe:
https://mafreebox.freebox.fr/api/v14/player/17/api/v14/system/reboot

Cependant, pour des questions de normalisation et de parsing, il faudrait que l’API renvoi une erreur avec un content-type application/json

Il serait bien de ne pas devoir développer un moteur de parsing HTML en plus du moteur de parsing JSON à cause d’1 seul message d’erreur renvoyé par l’API et “ne respectant à priori pas la convention de cette même API

Merci

Cordialement
nbanba

Chargement...

Activer les raccourcis clavier

Liste des tâches

Détails de la tâche

Édition de la tâche