12-04-2010, 06:47 PM
En même temps, je sais pas toi mais en général on change pas tous les jours sa politique de sécurité / affichage des inputs des utilisateurs. J'ai pas plus envie d'autoriser les failles XSS le mardi que le lundi. Quand bien même je changerais d'avis, la fonctionnalité ayant été inexistante auparavant, les utilisateurs normaux n'auraient pas essayé d'utiliser ces balises. Assurer une rétro-activité dans ce sens n'a... aucun sens, à moins que les internautes sachent qu'ils peuvent utiliser des balises qui ne servent à rien mais qui serviront peut-être un jour.
Enfin, je vois mal dans quel cas de figure on pourrait avoir un intérêt à insérer dans la base de données des trucs qui sont pas autorisés aux internautes. T'as peut-être un exemple concret ? Un retour d'expérience qui va dans ce sens ?
Pour ma part je gère beaucoup de données rédigées par des utilisateurs et celles-ci sont susceptibles d'être exportées : widgets, flux RSS, marque blanche... Et dans ce cas, c'est au fournisseur des données d'être garant de leur bonne intégrité. Balancer du code pourri ne fait pas sérieux. Mais même sans parler de ça, je vois toujours pas pourquoi des internautes iraient foutre des balises dans des inputs alors que celles-ci sont à ce moment-là inopérantes, à part à des fins malicieuses : tests, injections html, spam / création de backlinks. Et ces fins là il est clair que jamais je ne voudrais les autoriser.
Dans l'autre sens, si des balises sont actives un jour et doivent être désactivées un autre jour, elles seront déjà en base et un filtre a posteriori s'impose effectivement. Ce qui ne remet pas en cause un filtre a priori.
Enfin, je vois mal dans quel cas de figure on pourrait avoir un intérêt à insérer dans la base de données des trucs qui sont pas autorisés aux internautes. T'as peut-être un exemple concret ? Un retour d'expérience qui va dans ce sens ?
Pour ma part je gère beaucoup de données rédigées par des utilisateurs et celles-ci sont susceptibles d'être exportées : widgets, flux RSS, marque blanche... Et dans ce cas, c'est au fournisseur des données d'être garant de leur bonne intégrité. Balancer du code pourri ne fait pas sérieux. Mais même sans parler de ça, je vois toujours pas pourquoi des internautes iraient foutre des balises dans des inputs alors que celles-ci sont à ce moment-là inopérantes, à part à des fins malicieuses : tests, injections html, spam / création de backlinks. Et ces fins là il est clair que jamais je ne voudrais les autoriser.
Dans l'autre sens, si des balises sont actives un jour et doivent être désactivées un autre jour, elles seront déjà en base et un filtre a posteriori s'impose effectivement. Ce qui ne remet pas en cause un filtre a priori.