hello sympa ton outil.
Merci !
J'ai posté un PR avec 2 commits sur github ( https://github.com/p-dor/LiveboxMonitor/pull/44 )
- l'ajout d'un fichier .gitignore (standard python + Config.txt) pour éviter d'envoyer sa config dans des PR github et des fichiers de cache ou non source de Python
- la doc générée pour une Livebox 6 Pro (je serais intéressé de connaitre les différences d'API avec la 6 non pro).
PR maintenant intégrée au repo, merci.
Et j'apprends au passage que LiveboxMonitor fonctionne sur une LB6 Pro alors que j'étais persuadé que non, ayant pu regarder de près une LB4 Pro les firmwares n'avaient absolument rien à voir. Du coup je me demande ce que ça donne sur une LB5 Pro...
@Kana-chan m'ayant passé les fichiers pour la Livebox 6, je viens aussi de les publier, et cela permet de comparer.
J'ai regardé et c'est "rigolo", sachant que les versions de firmware sont strictement identiques :
- Les modules "Domino", "OrangeDynDNS" et "VPN" sont en "permission denied" sur la LB6 mais on voit bien toute la doc avec LB6 Pro.
- Il y a un sous-module "NMC.LAN" en plus dans la LB6 Pro, avec quelques méthodes permettant de manipuler des "Static Routes" et une sous ressource "NMC.LAN.IPv4Route"
- Comparer les deux gros fichiers _ALL_MODULES_ et _PROCESSES_ est plus compliqué car les choses ne sont pas générées dans le même ordre, ça vaudrait le coup de s'y pencher un peu car les tailles sont tout de même sensiblement différentes. Il est aussi possible que des modules supplémentaires soient documentés dans le fichier pour LB6 Pro et non présent en fichier individuel...
Je trouve que le coup du 'maintient la touche Ctrl' pour filtrer la doc devrait être par défaut (voir plus explicite) de façon a éviter la fuite de données sensible (j'ai failli balancer des données sensibles dans un PR public sans faire gaffe
).
Le truc c'est que l'utilisation standard de ce bouton c'est surtout de se générer sa doc privée, pas d'aller la balancer sur internet

Pour ça que j'ai considéré le filtrage comme exceptionnel, lorsqu'on veut partager comme ici.
Dernier point, quand on accède via un reverse proxy ou un tunnel ssh on ne peut pas forcement accéder au répéteur, il serait bien d'avoir une option pour spécifier l'ip:port du/des répéteur(s).
OK, cela risque de ne pas être si simple. Le mieux je crois serait d'ouvrir un ticket sur GitHub pour avoir un échange interactif pour trouver le meilleur compromis lorsque j'aurai le temps de regarder ça...