Iframe bloquée dans un design sous Bullseye (+ Erreur Javascript Content Security Policy)

Bonjour,

Orange Pi avec Jeedom 4.3.10 sur Armbian 22.08.2 Bullseye 32bits

J’ai un design qui appelle ce script Php stocké sur mon orange pi:

Et sur mon design:

<iframe src="http://monsite.fr:1981/espeasy.php?mode=view" style="border:0px #ffffff none;" name="esp" scrolling="no" frameborder="1" marginheight="0px" marginwidth="0px" height="841px" width="841px" allowfullscreen></iframe>

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:
image

Une idée pour m’aider ?

Hello,

D’après le log ci-dessus, il n’y aurait pas dû y avoir de blocage, donc ce n’est pas la politique CSP qui rend la page indisponible.

Est-ce que tu accès à ce site depuis une nouvelle page dans le même navigateur ?

Bad

Si tu entends par là « Ouvrir le lien dans un nouvel onglet » dans Chrome:

=> 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.

<iframe src="http://192.168.0.4/espeasy.php?mode=view" style="border:0px #ffffff none;" name="esp" scrolling="no" frameborder="1" marginheight="0px" marginwidth="0px" height="841px" width="841px" allowfullscreen></iframe>
1 « J'aime »

Je vois 2 adresse dans tes traces :

  1. http://monsite.fr:1981 et
  2. http://192.168.0.4/espeasy.php?mode=view

Normalement la 1) doit fonctionner partout et la 2) uniquement en local (normal, c’est une IP privée).

Si la 1) ne fonctionne pas partout, c’est :

  • soit un problème de résolution,
  • soit un problème de flux réseau.

Bad

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 image

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 ?

Et tu accèdes en local à ton Jeedom en https ou en http ?

http aussi bien local que distant

Tu as bien autorisé toutes les sources à se connecter sur ton ESP ?

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

1 « J'aime »

Alors là je ne sais pas trop…

Probablement pas un souci avec Debian 11, mais tu sais bien que ce n’est pas supporté pour le moment.

Pour en revenir à ton pb :
Es-tu sur que ton NAT entrant est OK ? Si tu te mets en 4G et que tu vas sur http://monsite.fr:1981 tu y accèdes bien ?

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 ?

1 « J'aime »

Attends juste pour être sûr http://monsite.fr:1981 est sur la même machine que jeedom ? C’est pas une redirection vers un de tes esp ?

1 « J'aime »

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 …

Bonjour Lenif,

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.

Bon ta remarque m’a mis sur la piste.

J’ai édité /etc/apache2/conf-enabled/security.conf

<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)

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.