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

  • Status Confirmé
  • Percent Complete
    0%
  • Task Type Anomalie
  • Category Freebox OS → API
  • Assigned To No-one
  • Operating System Freebox Server V7 (Delta)
  • Severity Low
  • Priority Very Low
  • Reported Version 4.9.0
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
Opened by nbanba - 23/03/2025
Last edited by 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

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing