Hello,
Dans le core 4.4 beta (MàJ core relancée avant) les tags html ne sont plus interpretés dans les logs non brut.
en 4.3 :
tandis qu’en 4.4 beta :
décocher et recocher Log brut ne résoud pas le problème
Helo @nebz,
En effet, par « mesure de sécurité », j’avais échappé tous les < et > rencontrés dans les logs lors de mon PR en mai, car il aurait été possible d’include des <script> ou autre dans les logs. Cf : 🔨 Faster and less bandwidth consuming logs display by BadWolf42 · Pull Request #2224 · jeedom/core · GitHub
Selon l’arbitrage de la Team Jeedom, je peux PR pour retirer les 2 remplacements.
Bad
Hello,
oui c’est peut-etre un peu extrème, peut être juste éviter les <script et peut-etre <img et <a href
En effet, tu as raison, j’aime bien l’idée de pouvoir utiliser des couleurs dans les logs.
Mais je partirais plus sur une approche ou tout est interdit, sauf certains tags, non ?
OK pour : <b>, <br>, <hr>, <i>, <span>, <strong>, <!--+-->
Peut-être : <div>, <em>, <li>, <ol>, <p> ?
Et avec uniquement des attributs : "class", "style" ?
Autre chose ?
Loïc, si tu passes par ici, tu as un avis ?
Perso j’aime pas l’interprétation du html c’est un gros risque pour la sécurité je trouve. Après si y’en a qui trouve ça indispensable alors juste interpréter certain tag semble le mieux
en effet plus sécuritaire dans ce sens là
j’aurais même tendance à dire <b> <i> <span> uniquement non ? que de la mise en forme basique… faudrait voir s’il y a autre chose dans les gens qui utilisent… j’ai été cherché l’info sur plugin-mirobot
de tout l’html peut-être bien, mais si on limite en max…
Le risque qu’il y a c’est que même dans une balise type span/b ou autre on peut cacher du JavaScript….
pas si on n’autorise que class
L’autre solution, c’est de définir les seuls tags utilisable « à la mode phpBB », par ex :
:color_red: ... texte ... :color_default:
Je ne suis pas super fan, mais ça à l’avantage d’être très secure et de rendre les logs brut plus lisibles.
j’aime bien aussi
oui car si on copie colle le log faudrait pas que la mise en forme soit copiée aussi…
Le modèle whitelist est indispensable vs blacklist.
Pareil, d’expérience je suis plutôt pour tout couper (sinon faut pas se faire d’illusion, il y a toujours une faille)
Mais si vous voulez absolument alors seul avoir une whitelist des balises acceptées est envisageable.
Je vous (et la Team) laisse trancher, je ferai un PR.
Ayant déjà regardé comment implémenter chaque solution, ça ne m’a pas l’air bien compliqué.
Le plus simple (et lisible) étant les balises persos (:warning: ... :end: ou [warning] ... [end]), mais du coup il faut créer et documenter une « norme ».
Le plus chaud (et consommateur) étant d’autoriser uniquement certains tag et attributs.
Et je serais dans tous les cas favorable à remplacer les \r\n ou \n par des <br>.
1 « J'aime »
(Bon tag ?)
Oui je pense 
tu n’as pas fait du log coloré dans les dépendances ?
Ah oui, en effet 3-4 span avec les classes « standard » utilisées cote log du core sur le type de log. (Juste que les logs que tu mets en 1er msg n etait pas de lui ! ^^)
Et puis j avais plutot encore un autre plugin en tete avec du html dans les logs ^^
On pourrait pas utiliser (une partie de) ca ?
Non, ca ne me semble pas adapté, c’est vraiment lourd à l’affichage en log brut
Bonjour
Pour moi (mais je pense jeedom sas sera d’accord) :
- dans un premier temps on supprime l’interprétation du html pour repartir d’un truc clean
- on introduit la possibilité des tags type :b ou :red
- pour pas que ça pose de soucis aux plugin on backport en 4.3
Après attention le soucis avec les :b et autre c’est que ça peut rendre la lecture en mode brute plus compliqué. Perso je suis pas pour un log et un log il est là pour aider au débug et pas pour être userfrienfly.
1 « J'aime »
La couleur VS la notion de « brut » a quand meme ete mis sur les logs cote core ^^
Pour que ca soit visuellement plus impactant.
Le fait de vouloir avoir ce genre de comportement egalement sur l install de dependance par exemple (cf 1er log proposé par nebz au depart de ce post) n est pas non plus déconnant et resterait dans la meme logique que ce qui est fait cote cote → rendre visuellement plus accessible le fait qu une des install s est potentiellement mal passée (entre autre)
1 « J'aime »