j’utilise ESPEasy depuis la mise à dispo du plugin, et ça fonctionne très bien sur mon Jeedom.
Mais:
j’ai installé ESPEasy sur un autre Jeedom (pas chez moi)
et ça fonctionne (il me semble) sauf que je n’arrive pas à accéder au ESP par l’équipement (en cliquant sur « interface web espeasy ») lorsque je suis connecté en local sur son jeedom, alors que l’ESP est accessible depuis son IP sur le réseau Wifi.
le jeedom est en version 4.3.10
la page santé est OK
le demon espeasy tourne et pas de problème pour activer les esp
mais dans les logs je n’ai pas vraiment la même chose que chez moi !
We have got a request for device=ESP_Sallon&taskid=0&cmd=Temperature&value=18.90 from 192.168.1.90
We have got a request for device=ESP_Sallon&taskid=0&cmd=Humidity&value=96.70 from 192.168.1.90
We have got a request for device=ESP_Easy&taskid=0&cmd=Temperature&value=17.40 from 192.168.1.39
We have got a request for device=ESP_Easy&taskid=0&cmd=Humidity&value=74.80 from 192.168.1.39
We have got a request for device=ESPS20_cuisine&taskid=0&cmd=Temperature&value=19.06 from 192.168.1.64
alors que chez moi, j’ai:
We have got a request for device=ESP_Shelly_02&taskid=0&cmd=Wifi&value=-62.00 from 192.168.31.254
Calling Jeedom http://127.0.0.1:80/plugins/espeasy/core/api/jeeEspeasy.php?apikey=xxxxxxxxxxxxxxxxxxx&device=ESP_Shelly_02&taskid=0&cmd=Wifi&value=-62.00&ip=192.168.31.254
du coup avant de faire une bêtise, si quelqu’un avait une piste ?
Est-ce que c’est une histoire de lien symbolique entre nodesjs et node (mais le demon tourne sur ce jeedom)
bon, ba je me trouve bien seul dans cette galère!
juste pour dire que le premier Jeedom (ou je n’arrive pas a voir l’esp via jeedom) est sur debian 11.3
et que le mien (pas de problème) est sous debian 10.6
mais pour moi ça ne change pas grand chose au problème vu que debian et moi…on est pas copain.
J’imagine qu’on parle de l’interface web d’ESP Easy. Du coup, il faut être connecté en VPN sur le réseau distant.
Il y a aussi l’option « Client IP block level » dans le page de configuration qui peut bloquer un accès quand on est pas en local. Le mieux c’est de le mettre à « Allow All ».
tu as la possibilité d’avoir « Accès à l’ESP »
mais pas possible ! alors qu’avec son IP j’y accède sur le reseau local (hors jeedom)
et tout est vert sur la page santé
vu que tu es sous bullseye, ça ne serait pas un problème de iframe ?
En tout cas, étant sous bullseye, j’arrive bien à acceder à l’interface ESPeasy quand je clique sur « Interface Web espeasy » dans jeedom en local. Par contre j’ai un warning de Security Policy qui s’affiche en haut à droite (d’où ma suspicion de problème iframe).
j’ai essayé de trouver quelque chose, sous les deux raspberry (l’un sous bullseye et l’autre sous la version d’avant)
c’est la même config pour apache et pour apache2 j’ai ce qui est plus haut, mais rien qui correspond a ce que propose Djelau, bon…pas grave.
Pour lire le fichier, ça doit etre faisable via Reglage->systeme->configuration->OS/DB-> Administration Système : Ouvrir puis taper la commande personnalisée suivante:
more /etc/apache2/conf-enabled/security.conf
Mais pour écrire je ne pense pas que ça soit accessible via jeedom. Il faut absolument un acces en ssh.
Orange Pi ou Raspberry Pi, c’est pareil, c’est du debian derriere.
j’ai réussi a récupérer les fichiers
pour celui sous Bullseye
si je reprends la ligne dont tu parles
Header set X-Frame-Options: "ALLOW-FROM http://monsite.fr"
ici j’ai header set X-Frame-Options « sameorigine »…donc ça devrait fonctionner mais Non.
et sur le mien sous buster j’ai DENY…donc ça devrait pas marcher et ça marche
Moi aussi j’avais X-Frame-Options « sameorigine » sous bullseye et ça ne marchait pas. J’en ai ajouté une avec « monsite » (j’avais jamais fait attention qu’il y avait déjà une ligne « Options »):
GNU nano 5.4 /etc/apache2/conf-enabled/security.conf
<Directory /var/www/html>
Options -Indexes -ExecCGI -FollowSymLinks
AllowOverride All
</Directory>
<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "sameorigin"
Header set X-XSS-Protection "1; mode=block"
Header unset X-Powered-By
Header set Referrer-Policy: strict-origin-when-cross-origin
Header set Permissions-Policy "accelerometer=(),battery=(),fullscreen=(self),ge>
Header set Content-Security-Policy-Report-Only "default-src 'self' file: data: >
Header set X-Frame-Options: "ALLOW-FROM http://monsite.fr"
</IfModule>
Et sous buster (un autre Orange pi que j’ai en backup/test), j’ai:
GNU nano 3.2 /etc/apache2/conf-enabled/security.conf
<Directory /var/www/html>
Options -Indexes -ExecCGI -FollowSymLinks
AllowOverride All
</Directory>
ServerTokens Prod
TraceEnable Off
<IfModule mod_headers.c>
# Content Security Policy (CSP)
Header set Content-Security-Policy` "script-src 'self'; object-src 'self'"
<FilesMatch "\.(appcache|atom|bbaw|bmp|crx|css|cur|eot|f4[abpv]|flv|geojson|gif$
Header unset Content-Security-Policy
</FilesMatch>
# Reducing MIME type security risks
Header set X-Content-Type-Options "nosniff"
# HTTP Strict Transport Security (HSTS)
Header always set Strict-Transport-Security "max-age=16070400; includeSubDomain$
# Clickjacking
Header set X-Frame-Options "DENY"
<FilesMatch "\.(appcache|atom|bbaw|bmp|crx|css|cur|eot|f4[abpv]|flv|geojson|gif$
Header unset X-Frame-Options
</FilesMatch>
# Reflected Cross-Site Scripting (XSS) attacks
Header set X-XSS-Protection "1; mode=block"
<FilesMatch "\.(appcache|atom|bbaw|bmp|crx|css|cur|eot|f4[abpv]|flv|geojson|gi$
Header unset X-XSS-Protection
</FilesMatch>
# Server software information
ServerSignature Off
Header unset X-Powered-By
# Weak SSL protocols
SSLProtocol all -SSLv2 -SSLv3 -TLSv1
</IfModule>
ErrorLog /var/www/html/log/http.error
Et comme tu peux le voir, j’ai également DENY et pourtant ça marche aussi chez moi sous Buster
Je ne sais pas mais à config équivalente, on a le même fonctionnement
c’est là où je bute un peu car je ne sais pas trop comment ça marche chez toi et comment ça marche avec ton VPN (et je suis pas expert en appache).
Je dirais qu’il faudrait mettre l’adresse externe (ou le nom de domain) du jeedom bullseye. Ou peut etre essayer avec son adresse IP interne vu que c’est un acces via VPN.
(désolé si j’enfonce des portes ouvertes) Par exemple je redirige le port externe 10808 vers le port 80 de mon adresse interne jeedom. Donc si je tape monsite:10808 depuis l’exterieur, je tombe sur mon jeedom. J’ai donc mis « monsite » (sans le port) dans les règles de security.conf.
Le AllowAll est je pense la partie dangeureuse de l’autorisation (éventuellement pour tester mais ça doit ouvrir pas mal de failles).
Ok, ce Jeedom passe par le DNS Jeedom, j’ai donc effectivement une adresse.
Mais je vois pas le rapport entre un accès par le DNS Jeedom et par l’IP local (qui fonctionne pas) mais je testerai quand j’en aurai la possibilité (si je dois être sur place, pas sur que je puisse modifier a distance)
Merci quand même pour ton implication.
