Bonsoir.
C’est la sécurité de Jeedom qui a fortement été améliorée pour la prochaine version de Jeedom. C’est un passage obligatoire.
Il y a eu des informations à ce sujet dans le blog de Jeedom.
1 « J'aime »
Salut,
Le problème est connu et les nouvelles sécurités posent en effet problème sur les menus.
Des adaptations ont déjà été faites par @Salvialf sur les menus ajoutés dans le plugin Pimp my Jeedom pour les problèmes de path.
Je dois regarder pour les menus proposés depuis mon github.
Par contre, ce qui n’était pas prévu à la base, c’est de bloquer les frames internes à Jeedom. C’est surtout ce point qui est bloquant actuellement pour continuer à utiliser ces menus avec ces dernières versions de Jeedom.
Il va donc falloir réfléchir à un contournement pour continuer à rendre utilisable ces menus et ce n’est pas si simple maintenant. A suivre…
Je crains que le blocage des iframes locales fasse fuir un peu plus d’utilisateurs vers HA.
La sécurité cyber oui mais pas au détriment de la finalité de la domotique locale.
2 « J'aime »
Hello @t0urista ,
Je suis comme toi j’utilise le design f$b33 mais celui d’origine du créateur, j’espère que je ne vais pas rencontrer le souci du changement de dossier car j’ai 5 écrans reparti dans la maison et chaque écran à des design différent.
Le passage de v3 à v4 à déjà perturber les widgets mais là si je rencontre trop de problème de passer en v4.2 quand elle sera dispo en stable je crois que je vais abandonner cette os.
J’aime bien la domotique mais j’ai pas que ça à faire de passer mon temps à refaire à chaque fois qu’il y a une évolution.
3 « J'aime »
j’ai à nouveau tenté 4.2.6 sur un Jeedom de test en appliquant mes sauvegardes a partir de 4.1.27 a 4.2.6 en 6 étapes.
les erreurs 403 sont toujours là en 4.2.6 alors qu’en 4.2.5 tout fonctionne correctement
fonts :
les fonts ajoutés (montserrat) ne sont pas rendues dans les designs
mes fonts sont pourtant correctement placées dans data/fonts avec la structure de folder adéquate :
var/www/html/data/fonts/Montserrat-Regular
-
style.css -
fonts -
Montserrat-Regular.ttf/
dans custom.css :
root {
–mainFont:Montserrat-Regular;
}
font-family : var(–mainFont) !important;
Message d’erreur Chrome : style.css : Failed to load resource: the server responded with a status of 403 (Forbidden)
http://192.168.0.210/data/fonts/Montserrat-Regular/style.css?md5=496fb4f128a543805bba3ae618d1d0cd net::ERR_ABORTED 403 (Forbidden)
menu design f$b33
j’ai deplace le folder montheme dans /var/www/html/montheme, les menus n’apparaissent toujours pas avec le message d’erreur Chrome :
data/montheme/menuHoverShow/json/perso.json?v=xxxxxxxxxx : Failed to load resource: the server responded with a status of 403 (Forbidden)
que me manque t’il ?
Avez vous testé avec la dernière alpha ?
merci kiboost
J’ai teste la derniere version 4.2.7 en alpha, cela regle les problemes de fontes/icones. les menus f$b33 de nodoon ne fonctionnent toujours pas, mais j’imagine qu’il faut encore les adapter.
En ce qui concerne l’absence de reponse de Jeedom après quelques temps, ne serait-ce pas du a un mecanisme de protection (IP bannie) du genre fail2ban ?
je m’explique :
J’ai essaye de me connecter a l’interface Jeedom à partir d’un PC, tout fonctionne bien , je passe d’un design à l’autre sans souci et puis soudainement plus aucune reponse de Jeedom, un ctrl-F5 donne une page blanche, le serveur a mis trop de temps pour repondre
je passe sur un autre PC, la ca marche à nouveau, mais similairement apres deux trois manip, plus de reponse
je passe sur un 3eme PC, idem.
Jeedom reste pingable et accessible en putty et WINSCP (SSH), donc pas de probleme de routage ou de Debian.
Se pourrait il qu’a cause de certains plugins, le browser continue a faire des requêtes vers des objets qui ne sont plus disponibles dans leur répertoire d’origine, a cause du nouveau controle d’acces du .htaccess, et que cela finit par bannir l’IP du PC client pour le serveur Apache seulement ? est ce plausible ?
Quel log pourrais je prendre ?
Des accès à des fichiers plus la pas après un f5
Tu n’aurai pas un widget qui met le bronx ?
j’ai désactivé fail2ban (/usr/bin/fail2ban-server stop) et le probleme de non reponse disparait immediatement, jeedom est a nouveau ‹ responsive ›.
j’imagine que des widgets non adaptés continuent a essayer de charger des objets a partir de repertoires non autorises, ce qui pousse fail2ban à bannir l’IP du pc
je me pose la question suivante : est il judicieux d’introduire de tels changements de comportement significatifs dans une version 6 d’une beta, qui est appelee a passer en stable bientot ?
ne devrait on pas plutot stabiliser la 4.2 actuelle, en n’introdusiant plus que des bug fixes en 4.2, et garder tous les nouveaux comportements et fonctionnalités pour une potentielle 4.3 ?
A ce rythme là une 4.2 stable ne peut qu’etre retardee.
Ces changements ne datent pas de la 6 l’alpha est feature fixed depuis qql semaines et la 4.3 a déjà commencé …
Nous vivons aussi une époque où la sécurité n’est pas une option, on nous le rappel souvent.
2 « J'aime »
Je comprends bien que la sécurité est importante, et qu’il faut etre tres reactif
Mais comment expliquer alors que chez moi ce changement de comportement n’apparait que dans la version beta 6 de la 4.2 ?
bonsoir de toute évidence tu doit pouvoir t’ auto répondre a cette question non ?
la seule explication c’est qu’il y a un changement majeur entre 4.2.5 et 4.2.6…
ce qui est tard pour un tel changement dans une version supposée etre stable bientot.
il y a probablement des widgets/plugins qui fonctionnaient bien avant et qui subitement ne fonctionnent plus suite a un changement sensé etre mineur
Sur alpha et bêta le dernier n° est important … les changements mineurs n’ont eux pas de N°
on fait la mise a jour et c’est tout !
De plus ce changement a été introduit il y a plusieurs mois (je dirais juillet ou août peut-être même avant) c’est pas un changement de dernière minute comme tu le dis c’est juste que tu n’as pas du mettre a jour ton jeedom tous les jours comme il faut le faire quand on est en beta (en beta le numéro ne change pas a chaque changement de version)
Enfin il y aura une solution pour revenir à l’ancien comportement qui sera volontairement complexe a mettre en œuvre et très risqué mais ça sera possible.
1 « J'aime »
Merci de vos réponses
perso je reste toujours convaincu qu’au dela d’une version 3 d’une beta il ne devrait plus y avoir de changement de comportement mais uniquement des bug fixes, cela accélère la transition en stable.
ceci dit, j’ai trouve une solution a mon problème, cela peut servir a d’autres, en modifiant le fichier .htaccess, en rajoutant l’accès aux fichiers json et xml, quel que soit le répertoire.
plus de bannissement d’IPs et les menus de noodom fonctionnent a nouveau.
est ce que ce changement (bug fix 
)pourrait etre incorpore dans les nouvelles beta/alpha ?
# Allow all :
<FilesMatch ".*\.(css|map|js|jpeg|jpg|png|php|html|svg|woff|woff2|ttf|m3u8|ts|ico|gif|webp|mp3|aac|json|xml)$">
Order Allow,Deny
Allow from all
</FilesMatch>
EDIT apres fermeture du post suite au commentaire de Loïc
j’ai trouvé une autre solution, en rajoutant un fichier .htaccess dans chaque répertoire customise dans lequel se trouvent des fichiers qui doivent aussi être accessibles en http(s).
pour les menus de noodom par exemple, j’ai rajouté ce fichier .htaccess dans le répertoire montheme
Order allow,deny
<Files ~ « .(json|xml|css)$ »>
allow from all
Cela fonctionne, et semble résister aux mises a jours de Jeedom
Le changement de sécurité est en grande partie pour justement ne pas faire ce que tu fais… L’idée c’est que ce type de fichier ne soit pas directement accessible (surtout ceux dans le répertoire data) car certains peuvent contenir des informations critique (clef du réseau ZigBee par exemple voir pire, beaucoup pire). Rajouter les extensions que tu demandes reviens à virer toute la nouvelle sécuritée mise en place ce n’est donc pas possible désolé.
1 « J'aime »