Commentaires sur : Réflexions sur l’élaboration d’un bon backend

Par : Nil

Nil — Wed, 02 Dec 2009 18:48:45 +0000

Merci bcp,

Ton tuto m’a bcp aidé

Par : NiKo

NiKo — Mon, 02 Nov 2009 16:04:27 +0000

Ah oui, Geoffrey++

Par contre tant qu’on a pas de fonctions anonymes en php c’est relou pour gérer un décorateur passé en argument.

Sauf en 5.3, bien entendu.

Par : SomeOne

SomeOne — Fri, 09 Oct 2009 12:11:55 +0000

Merci pour ce petit billet fort sympathique. Il y a quelque jour je me posé la problématique du lien filtrant que je n’avais pas sue résoudre.
Ton billet m’a bien servie en ce sens bien que je ne l’ai pas lue pour ca a la base.
Merci

Par : Geoffrey

Geoffrey — Wed, 30 Sep 2009 13:19:46 +0000

Heu moi ce que je ne comprends pas c’est ce que vient faire ce link_to dans un modèle ?

C’est une pratique déconseillée, déjà parcequ’elle incite à faire des trucs pas bien (désactiver l’escape_strategy), ensuite parceque c’est pas unit testable (ou disons, moins unit testable) puisque ça présuppose qu’on ait le helper chargé, et puis aussi, un modèle n’a pas a renvoyer du html, on est dans le M là, pas dans le V.

Par : Calu

Calu — Wed, 30 Sep 2009 09:46:05 +0000

@NiKo en effet, cela doit seulement s’appliquer sur des éléments non renseignés par l’utilisateur pour éviter toute injection Javascript ou même HTML. La solution est donc d’afficher le lien au travers d’un partial contenant notre objet et qui serait renseigné depuis le generator.yml.

Par : NiKo

NiKo — Wed, 30 Sep 2009 08:46:10 +0000

Je me méfierai personnellement du sfConfig::set(‘sf_escaping_strategy’, false) ; en effet, quid si un utilisateur a entré en front office un élément contenant une injection de code javascript ? Il sera executé lors de l’affichage en back-office, avec à la clé des effets dommageables potentiellement importants (vol de cookie de session, modifications du DOM, actions arbitraire sur les liens présents…)