L’acces externe via mon nom de domaine ne pose pas de problème. En revanche l’accès via IP interne me renvoie l’erreur suivante:
http://192.168.0.4/index.php?v=d&p=plan&plan_id=4 0 La ressource "http://monsite.fr:1981" a été chargée, mais elle va contre la directive de Content Security Policy :
"frame-src 'self' *.jeedom.com *.google.com *.google.fr data:"
J’ai donc tenté de suivre ce post, en updatant frame-src 'self' http://monsite.fr:1981 *.jeedom.com *.google.com *.google.fr data:;" dans install/apache_security_custom (une copie du install/apache_security_unsecure). Puis j’ai rechargé cette configuration dans apache.
Suite à celà, je n’ai plus d’erreur de Javascript Content Security Policy mais la page ne s’affiche pas pour autant et je n’ai rien dans les log:
=> Non ça m’ouvre une page avec la même erreur que précédemment
Ah et sur mon design, si je change par mon IP interne, dans ce cas je perds l’affichage via mon nom de domaine externe et en interne ça fonctionne correctement.
Pour le 2), effectivement ça ne marche qu’en local.
Pour le 1) ça ne fonctionne pas en local avec cette ligne dans mon design <iframe src="http://monsite.fr:1981/espeasy.php?mode=view" ...
Ca fait plusieurs années que ce script tourne mais je ne sais pas depuis quand ça ne fonctionne plus en local. Je viens juste de passer sur bullseye + maj 4.3.x et c’est en vérifiant s’il n’y avait pas eu de regression par rapport à buster que je me suis aperçu de celà (Mais j’avais peut etre déjà le pb sous buster. Je viens de tester avec un jeedom 4.2.16, pas d’erreur CSP mais
Si je rentre directement http://monsite.fr:1981/espeasy.php?mode=view dans chrome, j’accede bien à ma page aussi bien sur un pc/telephone en local que distant. Donc pour moi la résolution est OK mais je vois pas trop où chercher pour résoudre ce problème de flux (coté box internet ?). Ou alors c’est du coté de mon script php ?
Y en avait 1 sur mes 20 mal configuré. Ils sont maintenant tous en Allow All avec uniquement upper range 255.255.255.255. => mais toujours monsite.fr:1981 n’autorise pas la connexion
Debian 11, mais tu sais bien que ce n’est pas supporté pour le moment => Oui
Es-tu sur que ton NAT entrant est OK ? => Oui (port 1981 vers port 80 de 192.168.0.4)
Si tu te mets en 4G et que tu vas sur http://monsite.fr:1981 tu y accèdes bien ? => Oui
Nouvelle tentative avec un autre orange pi en buster:
Orange pi (OPI) bkp: jeedom 4.0.61 Armbian 20.08.17 Buster 32bits (armv7l) (vieille sauvegarde de jeedom avec pleins de trucs manquants)
L’OPI bkp a aussi un design avec iframe src="http://monsite.fr:1981/espeasy.php et possede également le script espeasy.php. Dans le cas d’une connexion externe, l’OPI bkp va lancer le script hebergé sur l’OPI de pod => **192.168.0.4** n'autorise pas la connexion
En redirigeant mon NAT vers Orange pi bkp (port 1981 vers port 80 de 192.168.0.5), le script php s’affiche enfin sur mes 2 OPI (exécution du script hebergé sur OPI bkp).
Je tente de restaurer des versions plus récentes de jeedom sur mon OPI bkp tout en gardant buster pour voir comment ça se passe…
Ne pourrait ce pas etre un problème de droit d’accès sur mon fichier espeasy.php de OPI prod ?
euh oui, http://monsite.fr:1981 c’est l’adresse de mon jeedom de prod. Et sur celui ci, j’appelle http://monsite.fr:1981/espeasy.php?mode=view qui est un script (hebergé sur la même machine que jeedom) qui vient interroger tous mes esp pour me renvoyer un tableau de ce genre:
Et en passant, sur jeedom 4.3.10 sur buster, ça fonctionne comme attendu (en local avec cette ligne dans mon design <iframe src="http://monsite.fr:1981/espeasy.php?mode=view" ... ).
Ca serait un probleme lié à bullseye (php 7.4) ?
juste pour etre sûr, si tu as mis le script dans le dossier script, ce n’est pas le .htaccess qui provoque une erreur ? T’as essayé de le renommer pour tester ?
edit: en relisant depuis le début pourquoi mets tu ton adresse externe dans iframe de ton design si le script est en local ?
Perso, j’ai mis mon script sur un iframe avec l’ip locale (sans NAT) et uniquement autoriser la connexion dans le htaccess qui lui est justement là pour l’empêcher depuis une autre source …
non, mon script n’est pas dans le dossier script mais dans le dossier html.
Sous buster, si je mettais mon adresse interne dans le iframe, ça fonctionnait en local mais ça ne fonctionnait pas en distant . Si je mettais mon adresse externe, ça fonctionnait dans tous les cas.
Mais je crois que le probleme est lié à Bullseye. Car j’ai testé une fresh install sous buster puis sous bullseyes et j’ai juste créér un design appelant un script « hello world »:
Sous buster, avec iframe externe, pas de probleme que ce soit via un acces local ou externe. Avec iframe interne, impossible d’afficher le résultat du script lors d’un acces externe
Sous bulleyes, avec iframe externe, impossible d’afficher le résultat du script lors d’un acces local. Avec iframe interne, impossible d’afficher le résultat du script lors d’un acces externe
Les iframes sont de plus en plus décriés et ont vocation à disparaitre. Un peu comme le flash. C’est une faille potentielle. Certainement un paramètre désactivé par défaut qui bloque les iframes. Et en séparant le script en deux parties ? une partie dédiée pour l’affichage uniquement et l’autre pour l’update des valeurs ?
Ca je sais pas trop comment faire ? Un peu d’aide peut etre ?
Cependant, pour dédouaner une erreur due à mon script, j’avais fait un script tout simple « hello world »=> même probleme.
<IfModule mod_headers.c>
Header set X-Frame-Options: "ALLOW-FROM http://monsite.fr"
</IfModule>
Une sauvegarde et un redémarrage plus tard, ça a l’air de fonctionner correctement
Edit: Renommage du titre Erreur Javascript Content Security Policy dans un design => Iframe bloquée dans un design sous Bullseye (et Erreur Javascript Content Security Policy)