GSH standalone: "Merci de vous connecter à Jeedom avant de configurer la connexion avec Google"

Bonjour,

Une erreur bien classique, que j’ai rencontrée par le passé, vu ici 1000 fois, sauf que cette fois-ci je ne m’en sors pas et après plus d’une heure à tester pleins de trucs, je dépose les armes et je me résouds à demander de l’aide :grin: J’ai du louper un truc !

Mon installation:
Jeedom stable 4.3.17
plugin gsh 2022-09-13 08:41:31
Dépendances à jour. Démon allumé.
Page santé « vierge »:

Smartphone Samsung Galaxy S23+ Android 13

Le contexte: suite à toutes les récentes mise à jour de l’app google home, du nouveau portail web, je me suis rendu compte que ma routine de retour semblait ne pas marcher. Finalement elle marchait peut etre, mais en ouvrant l’application mobile Google Home je me suis rendu compte que les équipements Jeedom avait certains labels bizarres, j’ai demandé à resynchroniser les équipements, j’ai eu des erreurs, je me suis dit qu’il vallait probablement mieux dissocier et réassocier le compte comme j’ai du le faire 2 ou 3 fois par le passé. Sauf qu’impossible de réassocier le compte: "Merci de vous connecter à Jeedom avant de configurer la connexion avec Google " dans la page chrome intégrée à l’app Google Home.
Je suis évidemment connecté à Jeedom dans Chrome.

Je suis donc en configuration standalone. Avec les DNS jeedom. J’ai donc la configuration qui était déjà complétée et correcte. Je me suis bien connecté avec l’URL DNS jeedom dans Chrome, mais j’ai quand meme l’erreur dans Google Home. Quand je regarde les infos certificats et compagnie, on voit que le site est connu et que je me suis connecté dessus récemment.

Par dépis, n’arrivant pas à le faire fonctionner, je suis passé en direct via mon nom de domaine. J’ai donc desactivé les DNS, configuré mon accès externe (domaine + port), relancé le démon GSH, les nouvelles URLs sont apparues, j’ai corrigé les deux oauths et celle de l’action, en prenant soit de tout sauver.

Quand je me connecter à mon appli de test, j’ai bien l’URL de mon nom de domaine utilisée, mais exactement la même erreur.

J’ai pas vraiment de log pour en dire plus:

plugin gsh

[2023-09-11 23:18:10][INFO] : Lancement : sudo node /var/www/html/plugins/gsh/core/class/../../resources/gshd/gshd.js --udp_discovery_port 3311 --udp_discovery_packet 4A6565646F6D --pid /tmp/jeedom/gsh/deamon.pid --loglevel debug >> /var/www/html/core/class/../../log/gshd 2>&1 &
[2023-09-11 23:18:10][INFO] : Démon Google Smarthome local lancé
[2023-09-11 23:30:36][INFO] : Lancement : sudo node /var/www/html/plugins/gsh/core/class/../../resources/gshd/gshd.js --udp_discovery_port 3311 --udp_discovery_packet 4A6565646F6D --pid /tmp/jeedom/gsh/deamon.pid --loglevel debug >> /var/www/html/core/class/../../log/gshd 2>&1 &
[2023-09-11 23:30:36][INFO] : Démon Google Smarthome local lancé

logs démon:

discovery listening { address: '0.0.0.0', family: 'IPv4', port: 3311 }
discovery listening { address: '0.0.0.0', family: 'IPv4', port: 3311 }

Il me semble que je devrais avoir une entrée débug dans le démon quand google essaye de se connecter.

Coté sécurité, clé API google smarthome activée, accès restreint non coché, je ne sais pas si ça a son importance.

J’ai l’impression d’avoir fait le tour de la question, je ne vois pas ce qui peut clocher avec tout ce que j’ai essayé, j’ai jamais galéré autant pour faire connecter mon application de test.

Peut etre que certains parmis vous auront une idée plus claire que moi de ce que j’ai peut etre oublié de faire ou de tester !

merci !

Bonjour
Google a changé la gestion des cookies dans Google home, la correction a été faite dans le plugin mais en beta il te faut donc la version bêta du plugin. Pour info la correction ne vient pas de moi donc en cas de soucis je ne peux pas forcément faire de support dessus.

Ceci n’est bien sûr valable que pour le mode standalone.

Salut !

Je n’étais pas au courant, je viens de passer en beta, merci.

Sauf qu’avec mon nom de domaine comme avec le DNS jeedom j’ai maintenant une page blanche sur le téléphone. Pas d’erreur visible. Pas de logs dans le démon ou le service.

J’ai également supprimé les cookies dans Chrome. Je me suis reconnecté. Mais ça ne change rien. Donc ça a un impact, mais ca ne corrige pas le problème dans mon cas.

Ok je m’y attendais, c’est pas mon code et j’ai pas de quoi tester. Il va falloir attendre que la personne qui a soumis le code le corrige (j’ai deja fait une correction car une erreur dans http.error mais après le reste ca dépasse mes compétences).

Edit : par contre je crois le code marche que si tu es en local (sécurité en plus).

Qu’appelles tu en local ? connecté sur mon réseau local ?
Si c’est le cas oui je fais le test en local.

Hier j’avais fait les tests en 4G et en Wi-Fi juste au cas où ça pouvait avoir un impact sur le comportement.

Faut etre sur le meme réseaux que la box, de mémoire le code qu’on ma passé verifie si tu viens bien depuis une ip local.

Oui c’est le cas, je suis en Wi-Fi, chez moi.
Pour le reste ça passe avec des noms de domaines donc cloud google à chez moi, mais j’initie bien la procédure en local chez moi.

Ben alors je sais pas faudrait voir avec la personne qui a proposé les modifications de code, si tu as pas d’erreur dans http.error je pourrais malheureusement rien y faire.

Sais tu comment je pourrais voir ça et remonter également le problème ? c’est pas un depot opensource ?
Faut que j’ouvre un incident ?

edit: non aucune entrée dans http.error

C’est un utilisateur sur le community qui a passé le code, par contre j’ai plus le sujet mais il faudrait le retrouver et lui poser la question.

ici ?

Merci. J’ai posé la question, en espérant que Bad ait une idée ou puisse confirmer si sa correction est toujours censée etre fonctionnelle

Yop @guipom,

J’ai vu passer ton sujet ce matin et je me suis dit que je n’avais pas eu de problème avec Gsh depuis un moment, et donc que je n’allais par conséquent surtout ne pas y toucher :sweat_smile:

Mais il va finalement que je m’y plonge plus sérieusement :smirk:

Ça peut attendre ce weekend ? Je préférerais ne pas casser la reco vocale en semaine, je n’ai pas de pré prod pour ça, mais ça serait l’occasion :thinking:

EDIT : Si tu veux, on peut faire une prise en main à distance ce weekend, comme ça je pourrais prendre les traces qui vont bien et tester en live, car en y réfléchissant, remonter une infra de preprod est bien trop compliqué.

Bad

1 « J'aime »

Salut,

En fait non il n’y a je pense aucun problème avec GSH en lui même, c’est juste le flow initial d’association qui est cassé, je pense que le reste fonctionne toujours très bien.

Ca peut attendre le week-end ou plus tard, de toutes facons j’ai tellement de pannes jeedom en ce moment que ca n’en fait qu’une nouvelle qui vient s’ajouter aux autres, ca en devient triste.

Par contre c’est mon installation de prod donc je ne suis deja pas chaud quand le support jeedom souhaite intervenir, là je le suis encore moins, si je peux réaliser les opérations ou tests moi même je préfère. J’ai une horde de personnes qui n’attendent qu’une petite faille sur mes accès pour se faire plaisir donc je préfère éviter.

En effet, c’est « l’apairage » entre le plugin GSH et ton app coté Google dans ton tenant GCP, non ?
Ce flow est initié par l’app vers le plugin sur ton Jeedom, c’est à priori cette page qui est « blanche ».

Oui, bien sur, je pensais à un partage d’écran moins intrusif, via Discord, comme je fais d’habitude.
De toute façon, je ne peux pas faire les manipulations sur ton tenant GCP, ni ton smartphone :wink:

Je voulais commencer à débugger tout ça, le point d’entrée est donc bien
plugins/gsh/core/php/jeeGshOauth.php ?

J’ai juste fait ça, redémarré le démon, et relancé le process depuis mon téléphone et rien !
Je m’attendais à une petite entrée.
Ce n’est pas cette resource qui est attaquée ?

require_once __DIR__ . '/../../../../core/php/core.inc.php';
log::add('gsh', 'debug', 'init => '.init('response_type'));
if (init('response_type') == 'code') {

Qui a commité:
« You are no comming from internal address » ?

A part les fautes, j’ai eu une maj ce matin et j’ai maintenant cette erreur. DNS Jeedom, faut que je reteste avec mon nom de domaine. En local chez moi sur mon réseau Wi-Fi.

J’ai viré le code, je pense que de toutes facons ca ne doit pas marcher de vérifier ainsi surtout avec du NAT ou du reverse proxy mais bon là dessus j’en suis pas sur, je suis tombé sur un formulaire un peu tout cassé mais j’ai pu remplir les deux champs et c’est connecté !

Donc on est pas trop loin d’un truc qui fonctionne en fait !

Bonjour
C’est moi qui est ajouté ça suite à ton retour pour savoir d’où vient le soucis.

As tu testé en mettant ton IP local jeedom dans la configuration de l’oauth ?

Donc j’ai testé tout à l’heure avec nom de domaine, ca marche également.

J’ai donc deux soucis:
L’erreur comme quoi je ne suis pas en local
Le formulaire qui suit pour s’authentifier, des variables ne semblent pas remplacées et il y a du debug sous le formulaire.

Mais en zappant le code de controle j’ai pu associer mon installation dans les deux cas, DNS ou connexion directe.

Je n’ai pas testé avec une IP locale, non. C’est vrai que ca serait assez inhabituel, non ? pourquoi on restreint en local ?

Bonjour
Pour des questions de sécurité, avec l’IP local seul quelqu’un sur ton réseau peut faire l’association avec ton jeedom. En ouvrant tout n’importe qui qui a l’URL pourrait déclencher le processus pour peut qu’il y ait une faille de sécurité sur la page d’authentification et n’importe qui a accès à ton jeedom.