Oui, je sais bien, c’est ce que j’ai constaté. Ca n’empêche qu’il peut y avoir quelque chose à corriger dans le core 
Si tu veux tester
event = new Event('securitypolicyviolation')
event.violatedDirective = ';'
event.originalPolicy = ';'
window.dispatchEvent(event)
OK, c’est normalement fixé par ce PR :
@ngrataloup, tu peux essayer de replacer :
if ('SecurityPolicyViolationEvent' in window) { // Check browser support of SecurityPolicyViolationEnevt interface
window.addEventListener("securitypolicyviolation", function(event) {
var uri = event.blockedURI
if (event.originalPolicy && event.violatedDirective) {
var violation = event.originalPolicy.trim().split(';').find(e => e.trim().startsWith(event.violatedDirective)).trim()
if (event.disposition == 'enforce')
var msg = `Impossible de charger la ressource "${uri}", car elle va contre la directive de Content Security Policy :<br /> "${violation}"`
else
var msg = `La ressource "${uri}" a été chargée, mais elle va contre la directive de Content Security Policy :<br /> "${violation}"`
}else {
var msg = `Erreur de directive Content Security Policy sur la ressource "${uri}"`
}
jeedomUtils.JS_ERROR.push({"filename": event.documentURI, "lineno": "0", "message": msg})
$('#bt_jsErrorModal').show()
$.hideLoading()
})
par
if ('SecurityPolicyViolationEvent' in window) { // Check browser support of SecurityPolicyViolationEnevt interface
window.addEventListener("securitypolicyviolation", function(event) {
var uri = event.blockedURI
var msg = `{{Erreur de directive Content Security Policy sur la ressource "${uri}"}}`
if (event.originalPolicy && event.violatedDirective) {
var violation = event.originalPolicy.trim().split(';').find(e => e.trim().startsWith(event.violatedDirective));
if (typeof violation === 'string') {
if (event.disposition == 'enforce')
var msg = `{{Impossible de charger la ressource "${uri}", car elle va contre la directive de Content Security Policy :<br /> "${violation.trim()}"}}`
else
var msg = `{{La ressource "${uri}" a été chargée, mais elle va contre la directive de Content Security Policy :<br /> "${violation.trim()}"}}`
}
}
jeedomUtils.JS_ERROR.push({"filename": event.documentURI, "lineno": "0", "message": msg})
$('#bt_jsErrorModal').show()
$.hideLoading()
})
dans desktop/common/js/utils.js vers la ligne 47 et test stp ?
Bad
Bonjour @Bad
Le message d’erreur javascript n’est effectivement plus présent avec le correctif
Norbert
1 « J'aime »
Mais tu en as probablement un autre lié à un morceau de page qui se charge en dehors de Jeedom, correct ?
Dans ce cas, il faut relancer le script « Apache non sécurisé » regarder si c’est effectivement un problème de sécurité ou non, et adapter la CSP, cf :
Oui, c’est bien ca,
C’est dans les mains du dev du plugin (JC en l’occurrence)
Norbert
Ca va vite etre compliqué si chaque utilisateur « bidouille » (car la majorité ne va pas reelement savoir ce qu ils font) le fichier de securite apache. Et risque fortement de perdre tout l intérêt de la chose (securiser) si ya des ajouts dans tous les sens !
Le mieux ca serait quand meme d avoir un module standard dans le core qui sache/puisse gérer tout ca.
@Mips avait émis une (superbe) idee a ce sujet, il me semble
(
: en effet, sujet ici )
Oui je te rejoins.
La politique CSP est faite pour augmenter la sécurité, mais peut aussi grandement augmenter les problèmes. Elle ne devait pas être « enforced », le temps de trouver une solution de ce coté là.
Sachant que j’ai proposé cette solution à ngrataloup (et GotierLdl dans l’autre fil), car ils semblent avoir ce qu’il faut pour aller fouiller dans le code et se débrouiller
J’avais aussi proposé le PR initial pour que les utilisateurs aient de la visibilité sur ce qui rentre en violation de la CSP et puisse le remonter aux devs (core ou plugins) sans avoir besoin de chercher longtemps pourquoi tel ou tel contenu est bloqué.
Bref, un vaste sujet…
Je ne suis pas dev, donc n’ai pas accès à la proposition, mais avoir une « interface » de gestion qui permet de modifier ce paramétrage sans prendre de risque (ou en tout cas en les limitant !) me semble être une bonne chose …
Etre trop restrictif, c’est à coup sur inciter les utilisateurs qui n’y connaissent pas grand chose à tout ouvrir (cf une extension Chrome qui le permet en 3 clics) → impact sécurité inverse à ce que l’on souhaite.
ou peut-être une fonction du core qui permet (pour le dev d’un plugin, lors de l’installation du plugin ou install des dépendances, d’aller ajouter les bons sites nécessaires à son plugin)
En tout cas, bon courage sur ce point, la sécurité est indispensable, mais c’est toujours compliqué à expliquer
Norbert
C’était l’idée, mais la CSP est gérée par Apache directement (serveur web de Jeedom), donc c’est très risquer de laisser du code la modifier, car au moindre problème la réparation doit se faire en ssh…
En tout cas c’est le point de vu que Loïc a mis en avant sur le sujet, et je le partage.
Hello,
Je vais peut être faire le rabat joie. Mais je pense que vous vous faites des rêve.
Aujourd’hui Loïc a dis non pour le faire via une interface ou en dynamique. Et malheureusement c’est la seul personne qui prend des décisions la dessus.
Mettre un système dynamique peux créer des failles de sécurité, et je rappel que jeedom est au départ pour les pro. Et donc je les vois pas rajouter des possibles failles de sécurité a cause de la version communautaire, alors que les pro (Leur source de revenus principal) elle cherche a avoir le mois possible.
Le mieux qu’il pourrait faire, c’est un proxy directement dans le core. Mais on est toujours en attente d’un retour de Loïc depuis janvier. Donc je pense que cela est aussi tombé à l’eau.
Cordialement
Thibaut
Le proxy est de loin plus risqué en terme de sécurité qu’une config correcte des csp surtout si le changement de config est géré par le core.
Justement s’il n’y a pas de solution apporté dans le core on se retrouve avec des devs tiers qui bricolent des solutions (il doit y en avoir plusieurs), solutions pas du tout transparentes ni éprouvées qui, parce que c’est du code, contiennent des failles, c’est certain.
Ce type de sécurité doit être gérée par le serveur web, c’est son boulot, pas par du code applicatif homemade.
Hello,
Sauf que Loïc a dis qu’il ne ferai rien sur les CSP apache directement. Et qu’il réfléchirai a un proxy directement dans le core.
Après a vous d’argumenter a font, mais je pense que c’est peine perdue.
Après je me souviens que a l’époque tu étais pour le proxy de ton côté.
Pourquoi ce changement d’avis ?
Cordialement
Thibaut
Ce n’est pas un changement d’avis radical mais oui j’ai évolué dans ma position par rapport au post cité plus haut.
le proxy, soit, mais c’est un workaround pas une solution et je trouve qu’il y a trop de risque.
Des posts comme celui-ci il y en a eu d’autres, dans lesquels j’avais déjà donné ce dernier avis donc c’est pas neuf non plus comme position.
Donc comme tu dis, je pense qu’on a déjà fait le tour de la question et que maintenant on attend une direction où avancer.
Hello,
Je lis pas tout les post, mais a mon avis vous aurez jamais de direction ou avancé.
Je pense que de mon côté que la question est déjà plié du côté de l’équipe core jeedom.
Et je l’avoue que tout les post que j’ai vu aujourd’hui en recherchant les conversations de l’époque mon plus fais pense a du lobbying que a une discussion avec un répondant derrière de l’équipe en charge de cette partie.
Je fais partie des dev qui font ce que tu trouves de mauvais. Mais aujourd’hui je n’ai pas d’autres solutions pour faire les choses. Je sait qu’il y a surement des failles, mais nous l’avons toujours dis que nous sommes responsables et donc que l’on ai prêt à patch tout les failles détecté.
PS : @ngrataloup désolé d’avoir polluer un peux ton post. Hésite pas à demander la séparation de ma discussion avec mips si cela te gêne.
Cordialement
Thibaut
J’étais en voiture, @Mips a été plus rapide que moi 
je suis pas à 100% aligné ici 
Est ce que les pro ne prennent que des plugin officiels ?
J’en doute fort, mais peut etre que je me trompe ! (en tout cas, perso on a été approché de nombreuses fois par des pro pour JC, et j’imagine que c’est pareil pour vous)
du coup ne pas proposer de solution commune et globale, c’est justement laisser la possibilité d’ouvrir de nombreuses breches pour avoir des plugin parfaitement fonctionnel. (et donc … que les pro subissent également ces failles)
ou alors … laissez le choix au dev de lui même implémenter une solution de contournement, et du coup à nouveau laisser la possibilité d’avoir des failles des sécurités encore plus importantes (car non centralisées et souvent bricolées !)
du coup si c’est vraiment le cas, ça serait bien que l’info soit clairement donnée aussi.
histoire que les dev tiers n’attendent pas une solution pour rien, et commencent (du coup…) à bidouiller un truc pour que l’ensemble de leur plugin puisse fonctionner. (et qu’on cherche les failles )
Attention je parle pas d’installateur domotique, mais des installations pros mises en place directement par Jeedom.
Mais oui, nous sommes en partenariat avec plusieurs pros.
Donc oui la partie pro que je parle prend surtout des plugin officiel.
C’est déjà le cas, on le fait de notre côté, car pas de réponses claires du côté de jeedom.
Excuse moi, mais c’est une habitude de mon coté dans mon emplois, une non reponse est une reponse negative automatique.
Vous avez attendu plus que nous, nous on a déjà sauté le pas il y a plus de 8 mois… Mais sa tu étais déjà au courant vu que je t’avais envoyé la solution du proxy
Cordialment
Thibaut
Autant pour moi alors !
Oui car on voulait une solution + pérenne et « sans risque » !
(Et fondamentalement pcq ca me fait chier d implémenter cette rustine ! )
Ah !? T es sur que c etait « Thomas », moi ??
(Notre dernier echange est plutôt sur la page « mes box locales », sur lequel tu m as simplement dit que vous aviez galèré, mais … pas plus ^^ )
Non, pas de souci, ça reste dans le thème du post initial !