C’est juste un curl ou même si c’est du http un file get content et ensuite un écho de ce que que tu as récupéré et c’est ton image.
J’ai activé les règles de sécurité sur mon installation oui.
Je ne pouvais plus accéder aux tuiles et avec le proxy ça passe
2 « J'aime »
Donc :
$image = 'https://images.tuyaeu.com/'.$path;
$imageData = base64_encode(file_get_contents($image));
$src = 'data: '.mime_content_type($image).';base64,'.$imageData;
echo '<img src="' . $src . '">';
Ca résoud le souci en 4.2 ?
Et c’est plus sécuritaire ?
Oui c’est ça
Merci beaucoup :
Le proxy Php s’est bien, on en parlait déjà mais par contre, et je n’ai pas regardé le code encore donc je ne sais pas ce qui est fait, il ne faut certainement pas un proxy qui accepte n’importe quelle url http sinon toute la secu de jeedom apportée par les CSP est parterre !
Il ne faut passer qu’un morceau du path, le valider/nettoyer au cas où quelque chose y a été injecté et reconstruire l’url en Php en rajoutant et donc en forçant le domaine et le protocol;
Dans le cas contraire il suffira au code injecté de passer par ce proxy pour downloader ce qu’il veut sur le poste client, ça ou le télécharger en directe c’est pareil.
On est dans l’exemple parfait au « trop » de sécurité (celle qui casse les fonctionnalités), tue la sécurité voulue au départ.
Il faut un mécanisme par lequel des sites de « confiances » peuvent être rajouté à la liste, idéalement à la volée et seulement lors de l’affichage de certaines pages (pour réduire la surface) donc concrètement uniquement lorsque le widget qui en a besoin s’affiche par exemple ou uniquement sur la page de config qui en a besoin.
Pour me répéter encore autrement: s’il n’y a pas de solution propre offerte pour accepter certains sites de confiances dans certains cas où c’est nécessaire, une solution de contournement sera trouvée par un dev et cela créera une brèche (voir un boulevard); et à ce moment autant ne rien mettre au départ, ça fait moins de maintenance pour jeedom et ça ne donne pas une fausse impression de sécurité.
Ce proxy devrait être intégré dans le core, ainsi le cleaning est fait de façon centralisée, ça évitera que chacun redeveloppe (avec des erreurs) sa solution et les domaines cibles autorisés devraient être déclarés par les plugins dans leur config par exemple, le proxy vérifiera lors de la requête client que le domaine se trouve dans la liste du plug-in pour lequel la requête est faite.
Et autoriser le téléchargement d’une map depuis Google maps ce n’est pas un trou de sécurité.
7 « J'aime »
C’est ce que je suis en train de voir, je me laisse le weekend mais je vais surement revenir en arrière
Bonsoir à tous,
Je me permets de revenir sur ce sujet pour connaitre les bonnes pratiques à avoir dans le cadre des requêtes ajax.
J’ai en effet procédé à qq modifications dans mon plugin Verisure en vue d’être 100% compatible avec la v4.2. Notamment dans le widget où, pour afficher les informations des modules existants (température, état, humidité,…), je vais les chercher dans un fichier json régulièrement mis à jour.
J’ai dans un premier temps utilisé la méthode avec le fichier downloadFile.php et cela fonctionne bien mais comme certains de mes utilisateurs n’ont pas que des comptes « admin », je suis passé par une requête ajax pour palier à ce cas.
Et c’est là que ma question arrive 
Dans mon fichier verisure.ajax.php j’ai :
if (!isConnect('admin'))
throw new Exception(__('401 - Accès non autorisé', __FILE__));
}
J’avais procédé ainsi puisque l’action de création d’un équipement ne doit être fait que par un admin.
Masi du coup en rajoutant mon action pour la lecture du json, celle-ci doit être accessible à tout utilisateur connecté donc avec :
if (!isConnect())
throw new Exception(__('401 - Accès non autorisé', __FILE__));
}
Quelle est donc la meilleure façon de faire pour gérer ses 2 autorisations ? 2 fichiers xxxx.ajax.php ?
Avec chacun son niveau d’autorisation ? Ou un seul fichier mais dans ce cas comment gérer ces 2 niveaux d’autorisation ?
J’espère avoir été clair 
Merci d’avance,
Xav
Salut,
C’est toi qui voit j’ai envie de dire 
Tant que tu t’assures que les actions admin sont réservée aux admins, je pense pas qu’il y ait un choix meilleur que l’autre.
J’ai un plug-in ou j’ai un fichier, je test la connexion (sans admin) pour faire les actions non-admin puis je test le profil admin avant de faire les actions admins mais 2 fichiers ça me semble valide aussi.
1 « J'aime »
Merci !
Je viens en effet de regarder sur le plugin arlo.
En gros, il suffit de mettre les conditions à la suite :
if (!isConnect()) {...}
puis les actions pour tous les users !
if (!isConnect('admin')) {...}
puis les actions pour les admin uniquement !
Je ne comprenais pas comment je pouvais avoir 2 conditions et surtout comment les imbriquer. Mais c’est tout bête ! Si la condition n’est pas respectée, la requête s’arrête tout simplement !
Pourquoi je cherche toujours à me compliquer
Merci encore !
Xav
2 « J'aime »
Peut être vérifier quand même qu’il n’y a pas un cas ou tu rentre dans tes deux conditions… donc l’ordre pourrait être important… genre un admin est aussi un utilisateur connecté (et donc les deux passent !)
Yes l’ordre est important.
D’abord user puis admin.
Ainsi un admin passera bien le premier test ainsi que le second.
A l’inverse un user passera aussi le premier mais pas le second.
Hello,
Petite question CSP pour voir si vous avez une idée.
Comment faire pour afficher un mjpeg (donc un stream) qui est sur une camera dans le réseau par exemple, depuis les nouvelles configurations CSP ?
C’est affiché par la tuile avec un « img src » et le CSP autorise uniquement self, jeedom.com et google(.com|.fr).
J’ai pas d’idée sur comment faire. La methode downloadFile.php ne devrait pas fonctionner vu que c’est du stream. Donc si vous avez une idée je suis preneur.
Merci
Hello,
Regarde si le proxy fonctionne ou peux être adapter :
Cordialement
Thibaut
1 « J'aime »
Merci. J’avais vu mais le proxy fait un curl pour retourner le contenu. Sauf que le contenu change toute les secondes avec un mjpeg donc je vois pas comment ca pourrait passer. Mais je testerais pour voir
EDIT : Je confirme curl_exec supporte pas le format mjpeg et crash
Bonjour
Pour ton cas aucune autre solution que de passer en mode non sécurisé
Hello @Loic
Merci
Je leur fait ajouter leur domaine dans le CSP pour éviter de tout désactiver.
C’est dommage de pas avoir une méthode php pour pouvoir ajouter certaines choses, au moins du reseau local (ce qui limite fortement le risque Securité) surtout dans le cas d’affichage de caméra.
J’utilise pas le plugin camera mais il n’affiche pas sur le Dashboard un live des caméras ?
Non il affiche une image de la caméra.
Pour l’ajout j’y ait pensé mais déjà ça demande un redémarrage d’apache et surtout si l’utilisateur mets le moindre mauvais caractère c’est la ligne de commande pour récupérer jeedom donc trop risqué
Oui c’est ce que je me suis dit aussi 
Hello,
Petite question, quel est le chemin pour le dossier images qu’il faut privilégier finalement ?
J’ai modifié en mettant les images dans le dossier plugin_info, mais je vois différents chemin selon les plugins que j’ai…
Donc je suis preneur de la norme officielle.
Pour info ici https://doc.jeedom.com/fr_FR/dev/plugin_template
C’est desktop/img
Mais je vois par exemple des plugins, officiels ou non qui ont des chemins comme ceci :
desktop/images
ou
core/img
Merci pour vos retours