Oui, je comprends l’idée, mais quand j’associe mon compte Arlo à Google Assistant/Home, il ne m’impose pas d’etre chez moi.
En fait en soit j’ai rien contre, pourquoi pas, c’est juste que l’identification que je suis en interne ne semble pas marcher.
Bonjour,
Et si tu utilises les services cloud jeedom (comme pour arlo vu que tu compares) tu n’aurais pas non plus besoin d’etre en local ou autre.
La c’est le mode standalone qui oblige a faire tout ca (mode qui n’existe pas sur arlo par exemple et qui au passage n’est pas apprécié de google).
Je peux revérifier mais il ne me semble pas que la même procédure avec home assistant m’impose d’être en local.
Encore une fois je le redis même si j’insiste là dessus en fait peu importe, c’est plus contraignant mais on ne le fait en général qu’une fois de temps en temps, pourquoi pas.
Comment je peux débugger et partager les infos pour identifier la raison pour laquelle jeedom ne m’identifie pas sur le réseau local. Tu aurais une idée ? Comme ça on aurait je pense une étape d’association initiale fonctionnelle en béta, il resterait à comprendre pourquoi les labels restent sous forme de clés
Pour home assistant peut etre mais jeedom n’est pas home assistant nous faisons d’autre choix. Ici j’ai preferé renforcer la sécurité plutot que la facilité c’est un choix que j’assume.
Pour le debogage comme dit je n’ai pas fait le code donc je ne sais pas comment t’aider.
Ce n’est pas une API jeedom le network getUserLocation ?
https://doc.jeedom.com/dev/phpdoc/4.1/classes/network.html#method_getUserLocation
Si mais je vois pas le rapport, elle regarde ton IP source et tu dois marcher avec une IP local. Si tu reprends mes messages je te dis justement comment arriver en internal je sais pas trop quoi te dire de plus.
Hello,
Je viens de voir tes messages
Top, tant mieux si ça marche 
Pas besoin de session ce weekend du coup ?
Bad
Hello,
Il peut y avoir un problème avec cette approche :
La redirection ayant lieu vers un nom de domaine, associé à une IP externe, il est possible que, même en interne, Jeedom voit une IP non locale tenter l’accès. Par exemple s’il y a un reverse proxy en entrée et pas juste du NAT.
Peut être faudrait il revoir cette sécurité pour ouvrir le portail d’apairage un certain temps, en intérieur et en extérieur, plutôt que de brider les IP source ?
Bad
non, mais je pense que le plugin n’est quand meme pas fonctionnel pour passer de beta en stable, il reste à vérifier les deux points que j’ai mentionné. Par contre je peux confirmer que j’ai pu l’utiliser en DNS jeedom et avec mon nom de domaine. Mieux qu’en stable !
Je posais la question parce que je ne connais pas ce code de Jeedom, je sais juste que la determination d’une IP locale ou non est subtile en sélectionnant les bonnes entetes HTTP, ce n’est pas juste vérifier l’IP de l’appelant, comme je le disais et comme le reprécisait Bad.
Et c’est pour ça que je voulais savoir comment vérifier ce qui arrivait au plugin, pour voir pourquoi il refuse une connexion pourtant « locale ».
C’est justement ce que je disais plus haut dans la configuration côté Google sur l’oauth il faut mettre l’IP local de jeedom.
Il y a un truc que je ne comprends pas. Pour l’obtention du token initial, ok, ca passera par une IP locale.
Mais pour le refresh token et compagnie, il fait comment l’intent google pour rafraichir son token d’authentification par la suite avec des adresses locale ? il est permanent, sans expiration ?
C’est ton jeedom qui declenche le refresh en oauth et pas google qui te l’envoi…
En y reflechissant j’ai peut etre dit une betise dans le cas de google c’est jeedom qui est le serveur oauth donc google vient bien renouveller le token mais de mémoire tu peux configurer l’url de token et l’url pour la partie association dans l’interface de google.
Je n’ai que 3 URLs a configurer. La fullfillment URL, pour les intents, elle je pense que c’est indiscutable elle reste sur un nom de domaine. C’est Google qui execute sur Jeedom.
Et deux pour l’account linking.
Authorization URL, pour Oauth2 implicit flow, c’est elle je pense que tu suggères de toujours définir en local
Token URL, pour l’échange de Token. Pour moi celle-ci ne peut pas être définie en local.
Cependant pour moi il y a un risque. Je ne sais pas si Google peut de lui même redéclencher un implicit flow. Je ne pense pas, j’imagine qu’ici on a toujours besoin d’une action utilisateur.
Ben voila:
authorization url en local
token url : en distant
Et non google ne peut pas redeclencher une authotization flow, en faite ca lui sert juste a savoir ou te rediriger une fois l’authentification ok
Je viens d’essayer, je pense que Google refuse cette configuration pour l’Authorization URL.
Déjà en local mon HTTPS est autosigné, mais bon peut etre que ca marcherait quand même.
Ensuite je mets une IP locale dans l’URL. Et rien, il utilise l’ancienne valeur.
Il faut vraiment que je mette un nom domaine pas complètement bidon pour que la valeur change. Sinon il ne la prend pas en compte.
Si quelqu’un a la possibilité de confirmer, je viens encore d’y passer une bonne demi heure et ca ne passe pas. Je ne pense pas que l’IP locale soit une option acceptée, je pense qu’il vérifie la valeur.
Je viens d’y passer plus d’une demi heure, ca ne passe pas avec une IP
Ah et j’ai recassé mon installation, j’ai maintenant droit à : « No compatible devices were found in your [test] Jeedom account. »
Flute. J’aurais pas du y retoucher …
Ok dans ce cas faut changer effectivement le code pour enlever ce check.
Possible oui. J’espère que quelqu’un pourra confirmer, je m’y prends peut etre mal, mais si j’arrive à faire marcher avec des noms de domaines, les DNS, mais pas avec un nom local ou une IP locale, avec ou sans port de préciser, je pense que c’est qu’il n’en veut pas.
Ce qui m’étonne c’est qu’il ne l’indique pas, ni a la saisie, ni plus tard.
Pour les équipements j’ai bataillé avec la sauvegarde en ajoutant/enlevant des trucs bidons et c’est reparti.
Un truc qui manque sur ce plugin c’est aussi de pouvoir facilement se rendre dans sa configuration, comme tous les autres.