Brol, Le contenu du csp_report.txt est ?
Le 25 juillet 2016 à 17:52, brol <[email protected]> a écrit : > Le lundi 25 juillet 2016 à 11:29:21, vous écriviez : > > > Plop tout le monde, > > > Je viens de reprendre un peu le code pour offrir aux plugins tiers > > l'opportunité d'intégrer leur complément de directive CSP (behavior > > adminPageHTTPHeaderCSP). > > Il y aura donc 2 moyen de les régler : about:config et 1 behavior pour > les > > plugins qui le prendront en compte. > > > j'ai aussi ajouté un behavior plus générique qui permet d'intervenir sur > > toutes les entêtes HTP envoyées avant l'affichage d'une page de l'admin > > (behavior adminPageHTTPHeaders). > > > Avec ça on devrait pouvoir faire ce qu'on veut côté admin. > > > Côté public, je pense que je vais attendre un peu de retour en "prod" > avec > > la 2.10 et implémenter ça pour la 2.11. > > > Le 24 juillet 2016 à 15:03, Franck Paul <[email protected]> a > > écrit : > > >> Sinon et pour répondre à Benoit, j'ai choisi des directives pas trop > >> fermées (au détriment du risque) : > >> > >> Les scripts JS inline et l'eval sont autorisés > >> Idem pour les styles CSS inline > >> > >> Ça vaudra peut-être le coup de donner un coup de tournevis en allant à > la > >> chasse aux scripts et style inline et d'évaluer si l'eval JS peut être > >> interdit. Cela dit, maintenant qu'on a accès aux différentes directives, > >> tout le monde peut les modifier et faire les tests idoines. Vos rapports > >> seront utiles pour affiner ça. > >> > >> Merci > >> > >> > >> > >> Le 24 juillet 2016 à 08:00, Benoit GRELIER <[email protected]> a écrit > : > >> > >>> Je n'ai pas trop le loisir de tester actuellement, mais après quelques > >>> lecture sur le sujet ( très technique pour mon niveau de > compréhension, par > >>> exemple : > >>> > https://hacks.mozilla.org/2016/02/implementing-content-security-policy/ > >>> ) je retiens que: > >>> > >>> _Il y a encore des bugs, > >>> > >>> _l’implémentation n'est pas simple et demande du temps. > >>> > >>> _Ce peut-être effectivement un bon outils de contrôle pour la phase de > >>> dev d'une application et inciter à de bonnes pratiques. > >>> > >>> > >>> > >>> Coté admin pour dotclear, le fait d'ajout de plugins tiers plus ou > moins > >>> bien conçu ne risque-t-il pas de tout casser à l'affichage? > >>> > >>> Benoit. > >>> > >>> > >>> > >>> > >>> > >>> > Message du 23/07/16 19:43 > >>> > De : "Franck Paul" > >>> > A : "[email protected]" > >>> > Copie à : > >>> > Objet : Re: [Dotclear Dev] CSP côté admin > >>> > > >>> > Côté admin, je pense qu'on peut l'imposer. Par contre c'est côté > public > >>> ou il faudra permettre un réglage beaucoup plus fin ; mais j'ai mon > idée à > >>> ce sujet. Le 23 juillet 2016 à 14:51, Benoit GRELIER a écrit : > Je > pence > >>> que ce service devrait être optionnel ( sous forme de module > > >>> activable/désactivable ) et non intégré en dur dans le code. > > > > > > > > >>> -- > >>> Dev mailing list - [email protected] - > >>> http://ml.dotclear.org/listinfo/dev > >>> > >> > >> > >> > >> -- > >> > >> Franck — Operating Crocker’s rules (http://sl4.org/crocker.html) > >> > > > > > -- > > > Franck — Operating Crocker’s rules (http://sl4.org/crocker.html) > > > goret quotage powa \o/ > > v3291 quand le machincsp est activé, pu possible de textarea pour la > description du blog, idem pour les zones txt des widgets (en gros, pas > mal de textarea sont impactés). > > sinon, je me demande quand même l'intérêt du truc sachant que nombre > de plugins tiers ne sont déjà pas à jour pour une compatibilité à 100% > avec dc2.9.1, alors en remettre une couche d'incompatibilité ne > risque pas de diminuer un peu plus le catalogue des dits plugins > tiers ? > > -- > brol > > -- > Dev mailing list - [email protected] - > http://ml.dotclear.org/listinfo/dev > -- Franck — Operating Crocker’s rules (http://sl4.org/crocker.html) -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
