Et un copie/colle du code (je laisse le screenshot car la petite croix rouge n’apparait pas si on copie juste le code
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 défaut, c’est plus simple de mettre le code copié plutôt qu’une capture pour des recherches dans le code
Sinon, apparemment, le find ne retourne rien : aucun élément commençant par event.violatedDirective trouvé.
Donc tu ne peux pas appliquer la fonction sur un undefined (pas d’éléments retourné)
A voir si c’est un test sur le retour du find qu’il faut ajouter avant de faire le trim() ?
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 ?
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 :
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é.
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
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.
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.
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.
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.
: en effet, 