Refus Jeelink

zolico · Octobre 19, 2021, 11:45

Que je mette la clef api jeelink ou core (du jeedom source) dans le champs Apikey jeedom source côté cible ne change rien. La connections est refusée.

Claude69 · Octobre 23, 2021, 5:10

Hello @Loic.
Aurais-tu une idée de ce qui peut provoquer le refus sur certaines commandes et pas d’autres ?
J’ai tenté de recréer la commande, mais j’ai le même résultat.
Jeelink en bêta du 2021-10-20 01:05:21 et dernière maj de Jeedom en 4.2.5 le 2021-10-20 06:29:33
pour un des équipement qui pose problème, je détaille :
Virtuel Volets sur Jeedom 1 avec Etat, ouvre et ferme"
Etat est bien vu par Jeedom 2
sur Jeedom 2 les commande ouvre ou ferme sont refusés par le Jeedom 1

Loic · Octobre 23, 2021, 6:33

Non aucune désolé a voir si bcp de monde a le soucis sinon c’est probablement un soucis de configuration

ngrataloup · Octobre 23, 2021, 7:18

J’ai eu pour ma part ce souci avant l’installation de la beta de jeelink suite à l’install d’une 4.2.x. mais l’installation de la beta + régénération des clé api et reparametrage a réglé ce souci ( comme expliqué dans plusieurs thread)

Claude69 · Octobre 23, 2021, 9:55

Merci.
J’ai fait tout cela, mais j’ai toujours les commandes qui ne fonctionnent pas dans un sens.
Je vais ressayer de 0, mais je doute.
Ce dont je suis sur, c’est que le souci est arrivé avec les modifications sécurité de la 4.2 qui ont complètement bloqué Jeelink. Les bêtas suivantes ont permis à certaines commandes de passer, reste ce petit soucis.
Si je n’arrive pas à le faire fonctionner, je vais réfléchir à une solution provisoire pour passer mes commandes autrement.
Je me remettrai dessus lorsque la 4.2 passera en stable, et du coup il y aura plus de monde pour tester.

Claude69 · Octobre 25, 2021, 6:40

Hello
Je viens faire un point de la situation, si il y a des beta-testeurs qui peuvent regarder si ils ont le soucis, ou si je me rate quelque part.
Je précise que cela fonctionnait avant les modifs sécurités de la 4.2
Jeedom 1 :

Jeedom 2 :

« Etat » part de Jeedom 2 et arrive sans soucis sur Jeedom 1
« Ouvre » et « Ferme » partent de Jeedom 1 et provoque un refus sur Jeedom 2

Claude69 · Octobre 25, 2021, 7:30

Complément d’infos, mon monitoring avec Jeelink est également dans les choux

Sur les 2 Jeedom.
Je ne sais pas si cela peut être lié.

anon7911623 · Octobre 25, 2021, 8:04

Hello,

Alors pour avoir testé tout le week ou presque, jeedom 4.2.5 maj forcée, jeelink beta mis à jour, regen de clés de jeelink, tout est dans les choux sur mes 3 jeedom secondaires et 4 sur mes monitorings (source et cible inclus).

vu que c’est remonté …

Claude69 · Octobre 25, 2021, 8:22

Hello
Merci du retour.
On est bêta testeur. Le but est de faire remonter l’info.
Plus qu’à patienter.

anon7911623 · Octobre 25, 2021, 8:24

re,

Oui j’avais pas pris le temps de répondre, à force de test ;), je peux ouvrir l’accès au besoin

Salvialf · Octobre 26, 2021, 7:33

Salut,

J’ai regardé vite fait ce matin, et il semble bien que le blocage se situe au niveau des clés API :

github.com

jeedom/core/blob/beta/core/api/jeeApi.php#L41

      
        
            $_RESTRICTED = false;
            if (init('type') != '') {
            	try {
            		$plugin = init('plugin', 'core');
            		if (in_array($plugin, array('apitts', 'apipro', 'apimarket'))) {
            			throw new Exception(__('Vous n\'êtes pas autorisé à effectuer cette action', __FILE__));
            		}
            		if (!jeedom::apiAccess(init('apikey', init('api')), $plugin)) {
            			user::failedLogin();
            			sleep(5);
            			throw new Exception(__('Vous n\'êtes pas autorisé à effectuer cette action, IP :', __FILE__) . ' ' . getClientIp());
            		}
            		$type = init('type');
            		log::add('api', 'debug', __('Demande sur l\'api http venant de :', __FILE__) . ' ' . getClientIp() . ' => ' . json_encode($_GET));
            
            
		if ($type == 'event' && class_exists($plugin) && method_exists($plugin, 'event')) {
            			log::add('api', 'info', __('Appels de', __FILE__) . ' ' . secureXSS($plugin) . '::event()');
            			$plugin::event();
            			die();
            		}
            		if ($_RESTRICTED) {

Il faudrait passer les logs API en debug dans la configuration générale de Jeedom pour avoir un peu plus d’infos

Claude69 · Octobre 26, 2021, 7:42

Merci @Salvialf
Je viens de les passer en débug. Je post dès que j’ai quelque chose.

Phpvarious · Octobre 26, 2021, 3:19

Bonjour,
Si vous pouviez tester, sur un équipement qui est issu d’un virtuel sur votre jeelink cible de mettre la cle API virtuel du jeedom source pour confirmer une piste…

anon7911623 · Octobre 26, 2021, 8:06

hello,

je regarde demain probablement dans la mesure du possible

Claude69 · Octobre 27, 2021, 6:06

Hello @Phpvarious
Je regarde ça au plus vite.
Merci

anon7911623 · Octobre 27, 2021, 4:35

Re,

Je me suis battu tout l’aprem avec une zigate qui va finir en orbite, du coup pas pu tester, désolé. Je n’aurais pas bcp de temps dans les prochains jours pour le faire non plus …

zolico · Octobre 29, 2021, 9:50

Bonjour tous,

J’ai passé en debug les log API et je ne vois rien de probant.
Essayé aussi de modifier les clef api coté cible en mettant la clef api zigbee source ou zwave ou jmqtt en fonction des objets jeelink remontés; même constat, refus côté source.

Phpvarious · Octobre 29, 2021, 12:14

Bonjour a tous,
@Loic, je me permet de te taguer,
je vais expliquer mes recherches et « solutions »:

dans la function sendEqlogicToMaster() (L691) 'remote_apikey' => config::byKey('api')(L695)
récupère l’API du core car
$_plugin n’est pas renseigné
celle-ci est envoyé avec le real_eqType soit le type de l’équipement (virtuel, jmqtt…)
Ensuite dans la function execute() (L490)
$url = .... jeeApi.php?plugin=jeelink&type=cmd&apikey=' . $eqLogic->getConfiguration('remote_apikey');(L493)

donc le « cible » va exécuter la fonction avec les paramètres suivants :

plugin=jeelink
apikey=APIDUCORE

Résultat :
Le Jeedom source n’accepte pas la requête API car apikey (du core donc) ne correspond pas a l’apikey du plugin (jeelink).

Solution 1 (testé):
J’ai actuellement contourné le problème en modifiant la Ligne 493 :
$url = $eqLogic->getConfiguration('remote_address') . '/core/api/jeeApi.php?plugin=jeelink&type=cmd&apikey=' . $eqLogic->getConfiguration('remote_apikey');
par :
$url = $eqLogic->getConfiguration('remote_address') . '/core/api/jeeApi.php?&type=cmd&apikey=' . $eqLogic->getConfiguration('remote_apikey');

En faite en vérifiant pendant la rédaction de ce post, je m’aperçoit que c’est comme ceci qu’était la variable en stable.

Solution 2 : (pas testé)
modifier sendEqlogicToMaster() pour que le remote_apikey corresponde a l’apikey de real_eqType. mais en réfléchissant je doute que ce soit possible car tout les plugins ne génère pas d’apikey, , ou peut-être faire une vérification avant et d’adapter remote_apikey et real_eqType en conséquence.

Désolé, j’ai essayé d’être le plus clair possible.
n’hésite pas si besoin.

Bonne journée.

Loic · Octobre 29, 2021, 1:37

Ok je vois il ne devrait pas envoyé la clef api du core mais sa propre clef api. Ca sera corrigé dans la beta de demain

Phpvarious · Octobre 29, 2021, 2:25

Mais si il envoie sa propre clef api, ne retomberons pas dans un autre throw new Exception car si j’ai bien saisi l’ $url pour la fonction execute() sera de type :
/core/api/jeeApi.php?plugin=jeelink&type=cmd&apikey='APIJEELINKSOURCE'
et dans ce cas jeeApi (L78) refusera la requête du fait qu’on essaiera d’exécuter une commande (de EqType autre que jeelink) avec la cle api de jeelink !

Merci.