NetatmoPublicData - nouvelle méthode de connexion

Salut @jim005

Désolé mais la nouvelle méthode me laisse sceptique;
Un utilisateur ne doit en aucun cas accorder une telle confiance à un développeur-tiers d’autant plus quand on a le choix !
Même si on a pas de doutes sur ces intentions les risques de piratage de son serveurs existent et par l’occasion les données confidentielles des utilisateurs (email, coordonées-Gps…) peuvent se retrouver exposées.
Même à titre personnel( en tant que DEV), je ne prendrais pas cette responsabilité.

Donc à n’utiliser qu’en cas d’absolu nécessité.
Je n’en suis pas certain mais il me semble que Jeedom interdit ce genre de connexion… si @Loic passe par là ?

Merci

Merci de lancer le sujet.

Le plugin propose les 2 méthodes :

  • autonome (comme avant et par défaut), avec Client ID + Client Secret
  • via mon appli. hébergée.

C’est bien la deuxième qui est le sujet.

Je l’ai mis en place pour les raisons suivantes :

  • permettre à ceux qui n’ont pas d’accès externes de pouvoir utiliser le plugin. L’OAuth2.0 requière une url de callback.
  • simplifier l’usage sans avoir à créer une app.

Si tu choisis cette nouvelle méthode les donnés stockées sont :

Ce sont les informations affichées dans l’onglet debug de la page de Configuration du plugin.

Précision notable : l’autorisation demandée à l’utilisateur est uniquement : read_station (Méthode 1 : ownApp et Méthode 2 : hostedApp).

Le script hébergé et sa structure MySQL sont sur GitHub.

Bonjour
Malheureusement je peux pas répondre la faut voir avec jeedom sas, ce n’est pas a mon niveau que se décide ce genre de politique. Désolé.

1 « J'aime »

@Loic peux-tu nous éclairer sur certains points :

  • Où est le lien vers les conditions / règles à respecter pour un plugin Jeedom ?
  • Peut-on développer un service reposant sur le Cloud Jeedom, comme certaines applications officielles ? ainsi je poserai mon script passe-plat dessus :slight_smile:
  • Dans le cas d’un service cloud (ici mon script), quelle est la guideline à suivre pour informer les utilisateurs ? (message sur le market, case à cocher dans le plugin, etc.)

Merci

Je sais pas comment vous aider la, pour rappel je suis juste un développeur indépendant et pas en employé Jeedom sas… Et perso c’est truc de réglé/condition et autre c’est vraiment pas quelque chose qui m’intéresse ou que je maitrise. De mémoire j’avais mis en place des CGU que vous avez signé pour avoir le droit de publier un plugin donc tout doit être dedans normal (c’est pas moi qui les aient faite donc me demandé pas de vous expliquer ce qu’il y a dedans, je ne les ai même jamais lu).

merci @Loic

@limad44, je vois aucune limitation qui pourrait concerner cette approche technique sur les CGU Développeur : Jeedom Market

Ça serait déjà plus sérieux à condition que le script soit vérifié et validé mais j’ai un doute que Jeedom-SAS accepte un développement dans ce sens !

Si les utilisateurs vous communiquent des noms d’utilisateur ou toute autre information personnelle ou information permettant la connexion au service, ou si vos produits y ont accès ou les utilisent, vous devez informer les utilisateurs que leurs informations seront utilisées par vos produits et leur fournir un avis de confidentialité et une protection jugée adéquate sur le plan juridique. De plus, votre produit ne peut utiliser ces informations que pour les finalités expressément autorisées par l’utilisateur concerné. Si votre produit conserve des informations personnelles ou confidentielles communiquées par les utilisateurs, il doit le faire en toute sécurité et pendant la durée requise uniquement. Toutefois si l’utilisateur a choisi, par contrat distinct avec vous, d’autoriser la conservation et l’utilisation d’informations personnelles et confidentielles par vous ou par votre produit, les conditions de ce contrat distinct régiront votre utilisation de ces informations.

J’en comprend que c’est pas impossible en informant clairement l’utilisateur

Vous convenez que vous êtes seul responsable de toute violation des obligations mises à votre charge par le présent contrat, par tout contrat ou toute condition d’utilisation vous liant à un tiers et par toute loi ou tout règlement applicable. Vous convenez que vous êtes seul responsable des conséquences d’une telle violation.

J’en comprend que le développeur engage sa responsabilité juridique hors à ma connaissance un dev qui n’as pas de plugin payant ne fournis même pas une pièce d’identité on ignore qui est derrière.

En finalité je reste opposé à ce genre de choses sauf s’il n’y vraiment pas d’alternatives ce qui n’est pas le cas pour l’Api Netatmo.

Pour la petite histoire j’ai renoncé à une méthode similaire pour le plugin GRDF car je ne voulais pas prendre de risques ni pour moi ni pour les utilisateurs.

A minima, afficher un modal/prompt lorsque cette méthode est sélectionnée, informant que des données privés peuvent/vont transiter par un serveur tiers et que l’utilisateur te dégage de toutes responsabilités en cas de problème. Accessoirement inciter à n’utiliser cette méthode qu’en cas de stricte besoin.
Le modal doit être accepté pour valider la méthode.

Bonjour
Pour le service hébergé par jeedom sas c’est pas possible car :

  • c’est un système un peu spécifique en kubernete et nodejs qui est bâti en mode service donc il faudrait qu’on fasse toute une documentation dessus, un process de validation et de suivi. Clairement ya pas les ressources humaines pour.
  • on l’a déjà pour netatmo qui serait même utilisable avec d’autre plugin en vrai car notre service fait passe plat (il peut faire passer n’importe quel requête tant que netatmo répond c’est bon)

Hello,

Juste pour ajouter quelques éléments à la discussion:

  • utiliser le cloud jeedom pour les plugins tiers ne me semble pas du tout réaliste ni une bonne idée:
    • il y a quand même le problème du coût. jeedom decide de l’assumer pour ses plugins qu’ils soient payant ou gratuit, avec ou sans abonnement, soit, mais pour les plugins tiers c’est autre chose
    • c’est déjà difficile à comprendre pour beaucoup d’utilisateur qu’il y a des plugins officiels, tiers, payant ou gratuit avec ou sans support. Mélanger des plugins tiers avec des services officiels ça va ajouter à la confusion générale.
  • concernant les plugins, il y a de mémoire vaguement une règle qui disait que toutes les « resources » doivent être fournies avec le plugin.
    Bon on sait qu’il y a toujours les libs externes (d’où l’installation des dépendances) et ici on parle d’un plugin (gratuit) qui de toute façon doit accéder à un cloud.
    Malgré tout dépendre d’un service externe tiers ça me semble hors périmètre de « l’esprit » de la règle.
  • sinon je suis plutôt de l’avis de @limad44 sur le fait qu’un dev tiers ne doit pas commencer à héberger des « services » pour les utilisateurs. Ce n’est pas juste une question d’avoir confiance en x ou y. Il n’y a aucun contrat pour ca, aucun cadre.
    Légalement je doute que tu aies le droit de détenir la moindre information qui permette d’identifier une personne directement ou indirectement sans un cadre légal précis. Une modale pour accepter et « encrypter » un identifiant n’est pas suffisant: avec quel clé ? Comment est-elle sécurisé? Quel algo? Quel outil de monitoring pour prouver que personne n’a accès? Ton cloud est hébergé où ? En Europe? Il y a des dizaines de questions comme cela à se poser. le rgpd n’est pas là pour rien et ce n’est pas le seul règlement à respecter.

Edit: j’ai oublié de préciser que j’avais bien compris l’intention finale de rendre cela plus simple pour les utilisateurs et c’est une intention très louable. Je ne remet pas du tout en question cela.

2 « J'aime »