Je cherche à pouvoir récupérer l’IP d’un téléphone qui exécute l’application Jeedom Connect. La commande Adresse IP ne fonctionne que si le téléphone est connecté à un réseau Wifi.
Est-ce que vous auriez une piste de comment faire ça ?
Je vais regarder de mon côté sur les logs access d’Apache, je pense qu’avec une commande grep filtrée intelligemment je dois pouvoir faire quelque chose.
Je suis néanmoins preneur d’autres options si vous en voyez.
Merci !
Mes informations :
Jeedom Core : 4.2.21
Version JC : 1.4.1
DNS Jeedom : non
Equipements :
Téléphone Nicolas : v1.4.0 sur android [os : 27] (ws)
En fait je suis en WS, donc pas de logs Apache, je viens de tilter maintenant. Je vais tenter de grimper la verbosité des logs du plugin pour voir ce que j’obtiens à ce niveau.
Pou rma culture, pourquoi souhaites-tu l’adresse IP 4G de ta connexion. C’est une adresse interne, propre à ton fournisseur de service et non publique, donc tu ne pourras rien en faire.
En fait, je me connecte souvent en SSH sur la machine qui exécute Jeedom, et ce en partage de connexion depuis mon téléphone. Comme tu le soulignes justement, cette IP est issue de mon fournisseur de service et change fréquemment.
Je suis chez Orange, et j’ai développé une application CLI qui permet de la piloter (activation/désactivation wifi, et aussi configuration NAT).
Pour des raisons de sécurité je ne souhaite pas ouvrir un port externe à la box bindé au port SSH de mon Jeedom, même avec Fail2Ban. Du coup, je créé la règle NAT avec un filtrage IP… IP du téléphone.
J’aurais voulu dans l’idéal que Jeedom Connect puisse remonter périodiquement l’IP 4G de mon téléphone pour faire ça simplement, mais je pense que ça n’est pas possible en l’état.
J’ai a peu près compris, et je pense que ce que tu veux faire ne marche pas. l’IP que tu dois voir arriver chez toi sur ta box n’est pas l’IP 4G de ton tel mais l’ip publique de ton fournisseur qui lui fait du NAT (je schematise) entre son ip publique et ton tel qui a une IP privée sur son réseau.
Alors autant tu as raison dans un échange où le téléphone serait « serveur » (il n’est pas possible de faire par exemple du ssh vers un téléphone correctement configuré pour, il faut mettre en place un reverse tunneling, à ma connaissance justement parce que le NAT opéré par l’opérateur ne permet pas l’accès direct), autant l’IP fournie lors de la requête HTTP par le téléphone contient bien (en tout cas pour moi, avec le fournisseur que j’utilise) l’IP publique du téléphone.
Lorsque je réalise le flow décrit plus haut à la main (récupération de l’IP du téléphone, création du NAT filtré avec cette IP…) ça fonctionne, je cherche donc à automatiser ce processus un peu casse-pied.
Je pense que je vais faire plus « simple » : utiliser une app type Http Request Shortcuts afin de consommer une URL de l’API Jeedom qui contiendra cette IP, et ce manière périodique.
Je vais regarder de ce côté-là, également pour rentrer un peu plus dans le fonctionnement du plugin, et je te tiens au courant si j’arrive à quelque chose de concluant.
Merci pour ta réponse en tout cas
Compris, c’est bien l’adresse IP publique qui t’intéresse et pas l’adresse IP du téléphone. SI tu developpes, tu peux éventuellement la récupérer via https://www.monippublique.com/ par exemple et la transférer via une URL sur un virtuel Jeedom pour faire ce que tu veux ensuite
Chez moi, l’ip du téléphone remonte dans la vue "Utilisateurs" lorsque je me connecte à Jeedom via mon téléphone.
Avec un bloc code, il doit être possible de la récupérer.
Bonjour,
Je débute dans Jeedom, et je n’ai pour le moment pas mis les pieds dans la partie « interface » au sens large (vues, designs et personnalisation de widget). Suite à ton message j’ai essayé de créer une vue mais pour obtenir ce que tu décris, sans succès.
Qu’avez-vous mis dessus ? L’équipement téléphone ?
Alors en effet il y a cette info, que je vois pour la connexion active. Je vais creuser côté core pour voir comment je peux l’exploiter je vous tiens au courant.
Je reviens un peu (longtemps en vrai :)) sur ce sujet pour te confirmer que ce que tu suggères m’a permis de finaliser quelque chose de fonctionnel. Je me base sur la première session admin trouvée dans la liste (à adapter en fonction des usages).
Pour ceux que ça intéresse, voici ce que je fais dans le scénario (basé donc sur ta suggestion et mon appli CLI de pilotage de Livebox).
Il manque la partie de gestion d’erreurs avec l’envoi de notifications Jeedom Connect que je vais ajouter plus tard si échouage d’ajout de la règle NAT.
foreach(listSession() as $sessionData) {
$user = user::byLogin($sessionData['login']);
if('admin' === $user->getProfils()) {
$scenario->setLog("Utilisateur avec rôle 'admin' ({$sessionData['login']}) connecté. Vérification du tunnel SSH.");
$externalIpToWhitelist = $sessionData['ip'];
//$scenario->setLog(print_r($natData, true));
$natData = getNatList($scenario);
//$scenario->setLog(print_r($natData, true));
if(isset($natData[$dataPrefix.$sshNatRuleName])) {
$scenario->setLog("Règle NAT SSH trouvée");
if($natData[$dataPrefix.$sshNatRuleName]['SourcePrefix'] !== $externalIpToWhitelist) {
$scenario->setLog("IP extérieure de connexion différente");
deleteNatRule($scenario, $sshNatRuleName);
createNatRule(
$scenario,
$sshNatRuleName,
$externalIpToWhitelist
);
}
else {
$scenario->setLog("Règle NAT déjà valide. Rien à faire.");
}
}
else {
createNatRule(
$scenario,
$sshNatRuleName,
$externalIpToWhitelist
);
}
}
}
function getNatList($scenario)
{
$natData = [];
$resultCode = null;
exec('php /home/jeedom/livebox/livebox/bin/livebox nat:infos -f /home/jeedom/configuration.yml', $natData, $resultCode);
if(0 === (int)$resultCode && 1 === count($natData)) {
$scenario->setLog("Récupération des données NAT effectuée avec succès");
$natData = json_decode($natData[0], true)['result']['status'];
}
return $natData;
}
function deleteNatRule($scenario, $sshNatRuleName)
{
$result = [];
$resultCode = null;
$scenario->setLog("Tentative de suppression de la règle NAT {$sshNatRuleName}...");
exec("php /home/jeedom/livebox/livebox/bin/livebox nat:delete --id={$sshNatRuleName} -f /home/jeedom/configuration.yml", $result, $resultCode);
if(0 === (int)$resultCode && 1 === count($result)) {
$result = json_decode($result[0], true);
if(true === (bool)$result['result']['status']) {
$scenario->setLog('Règle supprimée avec succès');
}
}
}
function createNatRule($scenario, $sshNatRuleName, $externalIp)
{
$result = [];
$resultCode = null;
//$scenario->getData('IP_STATIQUE_INTERNE'),
// $scenario->getData('PORT_SSH_INTERNE'),
$scenario->setLog("Tentative de création de la règle NAT {$sshNatRuleName} : accès du port {$scenario->getData('PORT_SSH_EXTERNE')} -> {$scenario->getData('IP_STATIQUE_INTERNE')}:{$scenario->getData('PORT_SSH_INTERNE')} autorisé pour {$externalIp}");
exec("php /home/jeedom/livebox/livebox/bin/livebox nat:create --id={$sshNatRuleName} --ip={$scenario->getData('IP_STATIQUE_INTERNE')} --external={$scenario->getData('PORT_SSH_EXTERNE')} --internal={$scenario->getData('PORT_SSH_INTERNE')} --whitelist={$externalIp} -f /home/jeedom/configuration.yml", $result, $resultCode);
if(0 === (int)$resultCode && 1 === count($result)) {
$scenario->setLog('Règle ajoutée avec succès');
}
//$scenario->setLog(print_r($result, true));
//$scenario->setLog($resultCode);
}
$scenario étant une variable réservée par le core de Jeedom représentant l’objet scénario en cours.
Et afin d’éviter d’éventuels bugs futurs ou des confusions, j’aurai plutôt fait pour tes 3 fonctions.
function getNatList($_scenario) {
$_scenario->setLog("..................................
C’est inutile à mon sens et sauf erreur de ma part, car en PHP, comme dans beaucoup d’autres languages, la portée d’une variable est limitée au bloc dans lequel elle est déclarée. Ici, c’est la fonction. Comme la signature stipule un passage par valeur, c’est une copie de $scenario qui est créée dans le scope de la fonction, et la variable $scenario de la fonction sera détruite lors de la sortie de la fonction. Du coup, je pourrais améliorer ça en stipulant un passage par référence qui transmettrait alors l’adresse de la variable $scenario originelle sans la dupliquer (ce qui serait bien mieux dans ce cas-là).
D’ailleurs j’ai fait ça car je n’ai pas réussi à utiliser la variable globale $scenario à travers mes fonctions comme je devrais pouvoir le faire avec une variable qui semble globale. Je n’ai pas encore creusé dans le détail la manière dont $scenario est mis à disposition dans les scénarios.
Si tu as (ou quelqu’un qui lit) des billes sur ce qui est accessible ou non dans un scénario et sous quelle forme technique, je suis preneur !
De rien, ce n’est qu’une observation d’un néophyte.
C’est le comportement normal de PHP, mais sous Jeedom, je reste prudent.
J’y ai prêté attention car je fais la même chose que toi pour pouvoir débugger ce qui se passe dans mes fonctions sous scénario.
Le code du core est disponible dans la doc, sur ta machine Jeedom et sur github, et si tu en as la capacité (que je n’ai pas) tu peux répondre par toi même à cette question.
De rien, j’essaye de partager le peu que j’ai pu apprendre en lisant la doc et ce forum.
