Bad
Janvier 17, 2024, 6:22
29
Phpvarious:
Par contre
$line = htmlspecialchars($line, ENT_QUOTES | ENT_HTML5, 'UTF-8');
fait des dégâts lorsqu’on est en log brute
,
Oui, mais $line = secureXSS($line);
fait plus de dégâts avec <<<
en supprimant toute la fin de la ligne.
Phpvarious:
et idem en 4.4.
Oui, j’ai prévu de corriger aussi les logs bruts en 4.4, mais priorité à la « prod » en 4.3
Le problème est que la coloration est faire client-side en 4.3 et server-side en 4.4…
c’est pas le strip_tags qui met la zizanie ?
/**
*
* @param string $_string
* @return string
*/
function secureXSS($_string) {
if ($_string === null) {
return null;
}
return str_replace('&', '&', htmlspecialchars(strip_tags($_string), ENT_QUOTES | ENT_HTML5, 'UTF-8'));
}
function minify($_buffer) {
$search = array(
'/\>[^\S ]+/s', // strip whitespaces after tags, except space
'/[^\S ]+\</s', // strip whitespaces before tags, except space
'/(\s)+/s', // shorten multiple whitespace sequences
);
$replace = array(
'>',
Bad
Janvier 17, 2024, 6:35
31
Si si, c’est bien mon commentaire plus haut :
Je suis entrain d’amender le correctif en 4.3 pour faire ce remplacement client-side
Désolé j’avais pas vu ce commentaire
Je suis en ligne si tu as besoin d’un test
Bad
Janvier 17, 2024, 6:44
34
Je pense que cette fois-ci c’est bon, toutes les corrections à effectuer en v4.3 sont ici :
jeedom:V4-stable
← BadWolf42:fix-logging2
opened 01:18PM - 17 Jan 24 UTC
## Proposed change
Fix special chars in colored logs as per Community:
https:/… /community.jeedom.com/t/probleme-daffichage-dans-les-log-scenario/119365/16?u=bad
https://community.jeedom.com/t/probleme-daffichage-dans-les-log-scenario/119365/19?u=bad
## Type of change
- [x] Bugfix (non breaking change)
## Test check
![image](https://github.com/jeedom/core/assets/8396512/a07b9965-cac3-4817-a92d-11b2c30bda80)
Before:
![image](https://github.com/jeedom/core/assets/8396512/2f0145ab-7afa-47a0-b58e-b1400a213d7b)
After:
![image](https://github.com/jeedom/core/assets/8396512/914ad3a1-4602-4fc2-8a38-53be27a241cd)
## Documentation
N/A
C’est ok pour moi. (pas testé en interact)
Bad
Janvier 17, 2024, 6:55
36
J’ai remis la valeur exactement équivalente à utf8_encode($query)
(cf cette modif )…
Comme ça, pas de prise de risques inutiles.
Loic
Janvier 17, 2024, 7:06
37
Bonjour
C’est en stable pour l’instant j’ai pas changé le numéro de version. Ceux ayant des soucis pouvaient vous mettre à jour et me dire si c’est bon ?
2 « J'aime »
Je pense avoir fais toutes les modifs, toujours le caractère accentuè "à " qui est en js
Maj faite a l’instant et c’est ok pour moi, par contre je ne reproduit toujours pas ceci :
chez moi c’est ok
Edit : je reproduit bien, j’avais pas saisi que c’était dans un message
Chez moi le scénario :
Le log :
Edit : tu me rassures, j’ai testé sur 2 jeedom différentes
Peut-être parce que le jour se couchera
ça ne veut rien dire
J’ai un doute, en faite je pense que ce soucis existait déja avant les PR de @Bad .
je peux tester j’ai pas fait la MAJ
Je pense aussi, mais je n’ai plus de vieilles jeedom en service
Ca lèverai le doute :
copie ceci et envoie sur une commande de type message.
Ce #sjour# #jour# #smois# #annee# le jour se couchera à xxhxx. Il fait x° dehors et les conditions sont xxxxxx, la T° max prévue est de xxxx°
Nous fêtons les xxxxxx
Bien vu @Phpvarious
[2024-01-17 20:24:24][SCENARIO] Start : Scenario lance manuellement.
[2024-01-17 20:24:24][SCENARIO] Exécution du sous-élément de type [action] : action
[2024-01-17 20:24:24][SCENARIO] Exécution de la commande [Téléphones][Iphone 14 key][Notification] avec comme option(s) : {"background":"0","title":"","message":"je suis parti \u00e0 v\u00e9lo"}
[2024-01-17 20:24:25][SCENARIO] Fin correcte du scénario
"message":"je suis parti \u00e0 v\u00e9lo"}
Ce Mercredi 17 Janvier 2024 le jour se couchera \u00e0 xxhxx. Il fait x\u00b0 dehors et les conditions sont xxxxxx, la T\u00b0 max pr\u00e9vue est de xxxx\u00b0
Nous f\u00eatons les xxxxxx"}