Acces support pour technicien extérieur non jeedom

Utilisation du core de Jeedom
1

Bonjour a tous, j’ai une petite question.
J’installe de plus en plus de box jeedom ( officielle ou Vm ).
Dans ma prestation se trouve évidement le support technique et la arrive ma question :

Nous nous trouvons dans un cas ou la domotique laisse un accès à la vie privée des gens, je pense qu’aucun clients n’aimerai voir son technicien savoir a quelle heur eil est rentré. Ma question est la suivante :

Y a t’il un moyen d’accorder un accès temporaire, voir limité, a jeedom et ca de façon facile ? tout comme un accès support le ferai mais pour des tech qui ne font pas partie de l’organisation ?

Pour ma part , la seule solution actuellement est de mettre en place une double authentification sur le compte support ( google auth pour ma part ).
Le client a le code tournant sur son tel / machine, et peut dans le cas d’un support, filer un accès à son technicien qui a les log/pass de son coté. Ce n’est pas une solution incroyable dans le sens ou le code tournant est relativement rapide et ne laisse que très peu de temps au client pour envoyer le sesame avant qu’il ne change. Il ne peux pas non plus contrôler combien de temps l’acces restera ouvert.
Bref, j’ai hate de connaitre vos avis

Merci a vous

2

Salut,

Solution sympa sur le papier et j’apprécie que tu te soucies de la problématique.

Ce qui me choque également un peu ici c’est que ca n’apprend pas aux utilisateurs de ne jamais, jamais donner le moindre code d’accès ou mot de passe à un système. Ce doit être un automatisme.

Alors si à côté on fait des exceptions (tout à fait louable), ca introduit une sorte de légitimité à ce type de demande et certains vont aussi le faire si c’est leur « banque » qui les appelle pour demander le code de ceci ou cela…

Tu devrais contacter jeedom directement pour ce besoin, il y a peut être une solution pour les installateurs agréés.

Un plugin pourrait répondre à ce besoin :wink:

3

Et en faisant dès le départ un compte qui t’est propre mais non actif et que tu demandes d’activer le temps de ta prestation ?

3 « J'aime »
4

tu as déjà fait chauffer vscode ? :wink:

5

Github copilot l’a déjà écrit pour moi :joy:

(Mais non en fait, je n’ai pas de besoin)

1 « J'aime »
6

deux petits scénarios bloc code :

// id de l'user maintenance -> configuration -> OS/DB -> Administration base de données -> SELECT * FROM `user`
$user = user::byId("9"); 
// 0 = désactiver, 1 = activer
$user->setEnable(0);
  $user->save();

Ensuite tu créé un virtuel pour faire un on/off facile.

Et ton client active et desactive depuis l’app mobile (ou JeeMate ou JC)

6 « J'aime »
7

tu dois aussi pouvoir sélectionner par le login comme ça tu n’es pas obligé d’aller chercher l’ID propre à chaque install:

$user = user::byLogin("ton nom de login");
8

Personnellement, je crée un compte installateur (désactivé), et le client l’active quand il a un besoin (même principe que pour le support jeedom).

J’aime bien l’idée du virtuel.
idéalement, il faudrait une solution qui fonctionne avec un compte utilisateur :thinking:
un genre de « Run as administrator » sans mot de passe :slight_smile:

9

Si tu regardes dans la classe user du core il y a toutes les fonctions que tu peux utiliser comme par exemple modifier le profil du user, … Donc un « simple utilisateur » peut être porté à un profil admin puis rétrogradé ensuite mais perso je préfère la solution de @sagitaz de jouer sur le enable

10

C’est pas ce que je voulais dire :wink:
Je trouverais intéressant qu’un compte utilisateur est accès à l’activation / désactivation d’un compte support.
La gestion des droits étant un projet toujours en cours

11

Juste pour info, tu installes des jeedom chez des clients sans leur donner des droits admin?

12

je viens de tester et apparemment un compte utilisateur peut avec ce code activer un compte admin même s’il n’a pas accès à la partie « utilisateur » du menu système. A vérifier mais cela me semble potentiellement être un pb de sécu non?

13

comme dit plus haut, la gestion des droits est en cours de refonte totale depuis un moment chez jeedom.
La notion actuelle de droits est plus de l’affichage actuellement :wink:

Pour répondre à l’autre question,
pour des raisons évidentes, le client utilise un compte utilisateur (histoire de ne pas faire de bêtises).
Mais il dispose bien sur du compte admin de la machine sur papier libre en cas de besoin :slight_smile:

14

Wow je ne m’attendais pas a autant de réponses !

@Noyax37 Oui, plutôt pas mal comme problème de sécu.
En ce qui concerne le scenario c’est une bonne idée car le but est de pouvoir activer/désactiver facilement. Lors des supports on est plutôt en presence d’un utilisateur qui se cantonne a des menus simples via telephone, et non l’interface PC.

En effet jeedom pourrait accorder un accès de ce type au installateurs.

15

une petite amélioration je pense au code de @sagitaz qui évite de faire 2 blocs code, ça inverse le enable du compte « admin » (pour l’exemple) à chaque exécution (attention à ce que le compte admin ne soit pas le seul compte administrateur actif) :

$user = user::byLogin("admin");
$enable = $user->getEnable();
$enable == 0 ? $enable = 1 : $enable = 0;
$user->setEnable($enable);
$user->save();
message::add('utilisateur', "Utilisateur admin statut 'actif' = " . strval($enable));
16

Pas vraiment puisque c’est un scénario et un scénario à toujours les droits impériaux.

1 « J'aime »
17

Une idée de l’état d’avancement concernant la refonte de la gestion des droits sur jeedom ?

18

pas vraiment => tu lui as donné accès à ce code / virtuel, il ne peut pas le créer tout seul

Impériaux, carrément :joy:
j’avais pas vu ta réponse; au moins on est d’accord :slight_smile:

1 « J'aime »
19

je ne sais pas pourquoi tu répètes ca 3 ou 4 fois depuis le début du post… une source ou t’as vu que c’était officiellement en cours? tu sembles plus informé que nous :slight_smile:

20

Discussions avec Alexandre (en rapport avec le dév de l’AppV2 et les besoins spécifiques des intégrateurs) en fin d’année dernière :thinking:

enfin ce n’est pas le bon endroit pour en discuter :crazy_face: je corrige mes posts :wink: faudrait pas donner de l’espoir inutilement :joy: