[RESOLU] Utilisation de rapport (report)

[aztazt]

Bonjour à tous,

Je découvre les rapport jeedom aujourd'hui.
J'ai lu la documentation et quelque chose n'est pas précisé.
Lorsque je déclenche la création d'un rapport basé sur l'un de mon design (par exemple, mais peu importe), et que je me fais envoyer ce rapport (en PNG) sur mon Télégram, et bien l'image affiche la page de login de Jeedom et pas mon design.
Je passe sans doute à côté de quelque chose, mais quoi ? Vous pouvez m'aiguiller s'il vous plaît ?

Merci !

[Phil56]

Bonjour,

je ne connais pas Telegram, mais je pense que problème vient du plugin ou service Telegram. Perso j'utilise slack et je n'ai pas ce problème.
Il faut que le plugin/service permette l'envoi d'image.

Dans un autre post j'ai montré un des exemple que j'utilise.

viewtopic.php?f=23&t=46806#p753445

Tu peux tester avec une commande de type mail pour commencer ?

ken@vo
Phil

[loic]

Bonjour,
Je doute que ca soit télégram pour moi c'est pas normal et tu es pas le 1er mais on ne reproduis pas il faudrait ouvrir un ticket au support pour qu'on regarde

[aztazt]

Ok, j'en ouvre un ce soir

[aztazt]

Bon, impossible d'ouvrir un ticket d'incident en raison de la présence d'un plugin incompatible avec l'ouverture de tickets. Tant pis.
Et oui, sinon, bien entendu que ça n'a rien à voir avec Telegram, c'était juste pour décrire mon cas d'usage.

Creusons un peu.

J'ai regardé le code qui se cache derrière la génération de rapports (dans core/core/class/report.class.php), et en fait, une commande comme celle-ci est lancée pour générer la rapport:

Code : Tout sélectionner

xvfb-run --server-args="-screen 0, 1920x1280x24" cutycapt --min-width=1280 --min-height=1920 --url="http://192.168.0.161/index.php?v=d&p=plan&auth=XXXXX" --out="/var/www/html/data/report/toto.png" --delay=10000 --print-backgrounds=on

Le problème, c'est le token d'authentification dans l'url passée en paramètre. Ce token est obtenu à l'aide de la fonction user::getAccessKeyForReport().

Et cette fonction génère (et "sette") un très long mot de passe pour un utilisateur nommé "internal_report" et obtient un code Google 2FA afin de permettre l'ouverture de session pour l'utilisateur internal_report (et permettre ainsi la capture d'écran via xvfb-run).

J'ai modifié un peu le code PHP pour loguer le code 2FA et le Password généré par cette fonction, mais le code 2FA est systématiquement vide.
Voilà ma fonction modifiée (variable $google2fakey ajoutée pour pouvoir enregistrer le code généré dans un fichier):

Code : Tout sélectionner

        public static function getAccessKeyForReport() {
                $user = user::byLogin('internal_report');
                if (!is_object($user)) {
                        $user = new user();
                        $user->setLogin('internal_report');
                        $google2fa = new Google2FA();
                        $google2fakey = $google2fa->generateSecretKey();
                        $user->setOptions('twoFactorAuthentificationSecret', $google2fakey);
                        $user->setOptions('twoFactorAuthentification', 1);
                }
                $user->setPassword(sha512(config::genKey(255)));
                $user->setOptions('localOnly', 1);
                $user->setProfils('admin');
                $user->setEnable(1);
                $key = config::genKey();
                $registerDevice = array(
                        sha512($key) => array(
                                'datetime' => date('Y-m-d H:i:s'),
                                'ip' => '127.0.0.1',
                                'session_id' => 'none',
                        ),
                );
                $user->setOptions('registerDevice', $registerDevice);
                $user->save();
               file_put_contents('/var/www/html/data/report/debugjeedom.txt', '2FA=' . $google2fakey . ' Password=' . $user->getHash() . '-' . $key . '\n', FILE_APPEND | LOCK_EX);
                return $user->getHash() . '-' . $key;
        }

J'ai bien sûr tenté en passant le paramètre twoFactorAuthentification à 0 mais sans plus de succès, l'utilisateur internal_report doit se connecter en 2FA de manière obligatoire on dirait.
Mon fichier debugjeedom.txt contient ceci par exemple (j'ai modfié les clés volontairement) :

Code : Tout sélectionner

2FA= Password=YJREWABsawmC1ehJLGUDOF1hHjhjWuLe-ESxdsDI1mpGG2PNwFpwkljDSCDa3cZT6

Je ne suis pas allé plus loin dans le débuguage de la fonction 2FA...
Mon serveur est à l'heure, réglé sur les NTP de Debian.

Si vous avez une idée ?

[loic]

Bonjour,
Il n'y a pas de 2fa normalement pour cette user donc je doute que le soucis vienne de la...

[aztazt]

Merci pour ta reponse Loïc (et j'en profite pour te remercier en direct pour le boulot colossal que tu as fourni pour Jeedim en général). Je te garantis que lorsque je tape internal_report dans le formulaire d'authentification dans le champ nom d'utilisateur, un champ de saisie 2fa s'ajoute sous le champ password. Peut-être un bug que je traîne depuis longtemps, je ne sais pas. De toutes façons, j'ai tenté de me loguer avec cet utilisateur et la clé générée, et ça ne fonctionne pas. Vais-je vraiment devoir désinstaller mon market alternatif pour ouvrir un incident ? Quoi qu'au pire, je sauvegarde et je restaure après... je vais faire ça je pense.

[loic]

Ben je sais pas mais ya peut être un truc chez toi par contre la désinstallation du plugin en question ne suffira pas il faut repartir de 0 ou d'un backup d'avant le plugin car celui-ci modifie des composants système et pourrait même être a l'origine de tes soucis

[aztazt]

Ok, je laisse tomber alors.

[loic]

Désolé mais on a vraiment perdu trop de temps sur les installations jeedom ayant ce plugin (qu'on a pas autorisé de surcroît) on peut vraiment plus se permettre de faire du support quand il y a ce plugin MTN.

[aztazt]

Je suis dans l'informatique, je comprends tout à fait. Les dépannages / bidouillages que vous pouviez vous permettre de faire au début de Jeedom ne sont plus possibles. Trop d'utilisateurs, de plugins, besoin d'industrialiser les process, etc. Je sais de quoi tu parles, ne t'inquiète pas

[aztazt]

Bon, finalement ça m'embêtait, alors j'ai décidé de continuer le diagnostic.

Lorsque l'utilisateur internal_report se logue pour faire la capture d'écran, il le fait via la fonction loginByHash.

Code : Tout sélectionner

function loginByHash($_key) {

        $key = explode('-', $_key);
        $user = user::byHash($key[0]);

        file_put_contents('/var/www/html/data/report/dans-loginbyhash.txt', '1' . PHP_EOL, FILE_APPEND | LOCK_EX);

        if (!is_object($user) || $user->getEnable() == 0) {
                user::failedLogin();
                sleep(5);
                return false;
        }

        file_put_contents('/var/www/html/data/report/dans-loginbyhash.txt', '2' . PHP_EOL, FILE_APPEND | LOCK_EX);

        if ($user->getOptions('localOnly', 0) == 1 && network::getUserLocation() != 'internal') {
                user::failedLogin();
                sleep(5);
                return false;
        }
        
        file_put_contents('/var/www/html/data/report/dans-loginbyhash.txt', '3' . PHP_EOL, FILE_APPEND | LOCK_EX);
        
        
        

J'ai donc pu constater que le login ne fonctionne pas car network::getUserLocation() n'est pas positionné à "internal".
Je continue mes investigations (au cas où un futur utilisateur rencontre le même problème que moi et qu'il est dans l'impossibilité d'ouvrir un incident pour les mêmes raisons que moi.

[aztazt]

Bon, j'ai trouvé !

C'était simplement parce que dans le paramétrage réseau de Jeedom, au niveau de l'accès interne, j'avais spécifié le FQDN de mon serveur Jeedom (srv-jeedom.intra.mondomainelocal.loc) puisque je dispose d'un serveur DNS interne sur mon réseau local afin de pouvoir appeler mes serveurs internes par leur nom, c'est plus propre alors qu'en fait, il faut spécifier l'IP du serveur dans l'URL.

Sujet clos.