le menu f$b33 ne fonctionne plus depuis passge de 4.2.4 en 4.2.6 , de meme les fontes de caracteres personnalisées et images importées ne sont plus affichées
pour f$b33 les fichiers nécessaires sont stockes en /var/www/html/montheme et j’obtiens une erreur 403 Forbiden access sur Chrome
mes fontes personnalisees sont en /var/www/html/data/fonts
j’ai lu que les accès au fichiers ont ete modifiés en 4.2.6, que seuls certains repertoires etaient autorises pour l’accès aux fichiers par le serveur HTTP, Apache dans mon cas
faut il les deplacer ? j’imagine qu’en 4.2 stable j’aurai le meme probleme aussi ?
C’est lié à une modification du core puisque les fontes personnalisees ne fonctionnent plus non plus ainsi que les icones personnalisees
il y a donc bien eu une modification au niveau du Core qui impacte toute une serie de plug in. c’est le sens de ma question.
Je ne dis pas qu’il y a un un bug dans le core, je m’interroge sur les changements du core qui conduisent a ce nouveau comportement
pourquoi obtient on maintenant une erreur 403 pour toute une série de fichiers qui auparavant en 4.2.4 étaient correctement fournis par le serveur ?
comment puis je régler cela ?
Déplacez les fichiers dans /data, de mémoire ça devrait aller (mais je suis sur mobile pour le moment donc je ne sais pas vérifier)
Et bien sûr adapter les paths dans les design
Je m’attendais à voir cette question arriver
edit: je vais tester de mon coté pour valider la solution avant de la confirmer
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.
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.
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 ?
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.
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 ?
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
