• [^] # Re: Curiosité...

    Posté par (site web personnel) . En réponse au journal Offre d'emploi Développeur Web (Paris). Évalué à 2.

    Je trouvais ton premier message sur la gestion des slashs (addslashes, mysql_real_escape_string, ...) pour le moins étrange. Maintenant je comprends mieux et je suis d'accord avec toi. Mais tes arguments ne sont valables que pour une application dont on maitrise l'environnement (serveur, navigateur, ...).

    Il ne viendrait à l'idée de personne de déployer un binaire sur une machine sans vérifier que les dépendances vis-à-vis des librairies utilisées sont garanties. Pourquoi serait-ce différent pour une application développée avec php ?

    Si on essaie de déployer l'application, en revanche on se retrouve confronté à des problématiques toutes autres. Il faut ajouter toute une "couche" pour se rendre plus ou moins indépendant de la configuration du serveur. Dès que l'on fait une application qui est destinée à être déployée, un minimum d'organisation est essentielle. Une approche possible (pas la seule) est de se tourner vers une programmation orientée objet (mvc ?). Quoi qu'il en soit une programmation modulaire s'impose.

    Je partage ton avis sur la virulence des propos de Laurent:

    Bref, pour une appli pro un minimum robuste :

    1) on désactive les magic-quotes, ou au pire, on test si les magic_quotes sont activées et dans de cas on réalise l'opération inverse.
    2) dans les classes métiers (qui sont censées récupérer des données non échappées), on utilise la fonction d'échappement dédiée à la base utilisée. (ce sera pg_escape_string pour postgresql par exemple, ou mysql_escape_string pour mysql etc..)


    C'est une solution possible et uniquement si l'application est destinée à être déployé et que l'on ne maitrise pas la configuration du serveur.