Discussion :

[Benjamin Delespierre]

Bonjour à tous.

C'est bien connu, les mythes et les légendes du langage PHP ont la vie dure.
Je vous propose d'en faire un tour d'horizon pour tenter de les démystifier.

Je commence avec:

L'usage des guillements simples est plus performant que l'usage des guillements doubles.

C'est absolument sans fondement.

$_POST est plus sécurisé que $_GET

Absolument TOUT ce qui provient de l'utilisateur est par définition insécurisé pour l'application.

Une erreur ? Un arobase et hop, y'a plus d'erreur !

C'est bien connu, les erreurs c'est magique !

Si tu veux faire du PHP ? Il te faut impérativement un serveur web !

S'il y a un mode CLI c'est justement pour ça tiens.

PHP n'est pas un vrai langage objet.

Pas au sens de Java non (comme les puristes l'entendent), mais depuis sa version 5 on dispose d'une vraie couche objet.

[stealth35]

L'usage des guillements simples est plus performant que l'usage des guillements doubles.

oui et non

non :
echo "$a" est moins performant que echo $a
echo "$a test"; est moins moins performant que echo $a, ' test';

oui :
par contre echo "hello" et echo 'hello' c'est pareil

Une erreur ? Un arobase et hop, y'a plus d'erreur !

et en plus c'est pas performant

[grunk]

PHP n'est pas performant, pas fait pour les gros site

C'est pour cela qu'aucun gros site ne l'utilise (facebook , yahoo, ...)

PHP n'as pas d'outil de développement

Il existe de très bon IDE gratuit ou payant intégrant bien souvent un débugger (ZendStudio , Netbeans PHP, ...)

PHP est propice au code mal organisé, mal programmé

Il y'a du code dégeulasse en PHP, et c'est surtout du à la facilité d'accès du langage, mais un bon codeur produira du bon code.

Etre développeur PHP / Web ce n'est pas être un "vrai" développeur

(véridic et entendu)
no comment ? ^^

[gwharl]

Etre développeur PHP / Web ce n'est pas être un "vrai" développeur

(véridic et entendu)
no comment ? ^^

Dit par des développeurs java/.net je suppose, développer en PHP est surement plus facile d'accès mais en comprendre toutes les finesses demande à mon avis un vrai travail de programmation.

[Benjamin Delespierre]

Dit par des développeurs java/.net je suppose, développer en PHP est surement plus facile d'accès mais en comprendre toutes les finesses demande à mon avis un vrai travail de programmation.

Pas seulement. Dans l'entreprise où je travaille C, y'a qu'ça d'vrai !

[grunk]

Pas seulement. Dans l'entreprise où je travaille C, y'a qu'ça d'vrai !

Les développeurs C sont des extrèmistes , si y'a un Garbage collector , c'est pas du développement ^^ (humour je précise)

[Benjamin Delespierre]

Dans ce cas on peut considérer qu'avant la version 5.3 de PHP, on était des vrais développeurs

Au passage, j'aime beaucoup cette quote de Julien Pauli sur son twitter:

Developper/programmer diff? Progs use their brain to write solution to problems. Devs use theirs to compute how to use solutions progs wrote

[Retrokiller069]

Bonjour,

Absolument TOUT ce qui provient de l'utilisateur est par définition insécurisé pour l'application.

je suis d'accord avec ca par contre:

$_POST est plus sécurisé que $_GET

Je ne suis pas entièrement d'accord avec le fait que $_POST n'est pas plus sécurisé que $_GET. Le fait que $_GET passe par l'url permet de récupérer plus facilement les informations (je pense) que $_POST (ou du moins la difficulté pour le récupéré via un $_POST n'est pas à la porté de tous). Vous serez d'accord avec moi sur le fait qu'il est inconcevable de mettre en $_GET des informations de type mot de passe (surtout s'il y est crypté) ou login . Le "plus" n'est peut être pas très énorme mais il est quand même présent.

[Agnello Fabrice]

Il y'a du code dégeulasse en PHP, et c'est surtout du à la facilité d'accès du langage, mais un bon codeur produira du bon code.

Je suis assez d'accord. PHP se traine de bonnes casseroles (parfois à raison) depuis PHP/FI et est souvent qualifié de "toy language" avec lequel on ne fait que du "quick and dirty". A mon sens (qui rejoint le votre), c'est sa relative simplicité qui est à l'origine de ça (typage faible, scripting, etc.). Les développeurs de l'époque - principalement issus du client/serveur et de l'embarqué - (dont je fais partie) ont réservé un accueil un peu plus sympathique à Java (ex Oak), qui lui, était compilé et proposait un typage fort ne bousculant pas (trop) les habitudes.

L'avènement des frameworks (y compris lorsque nous étions encore en non-objet) a permis la structuration du code php et des design-pattern comme le MVC et MVC2 ont amené la dimension "professionnelle" qui manquait à PHP.

Il reste tout de même qu'une autre légende urbaine veut que PHP soit cantonné aux sites perso/vitrine/whatever, mais ne convient pas pour des applications professionnelles type ERP ou métier. Là aussi c'est éminemment faux, mais ce mythe a la dent dure à tel point que les entreprises vont y préférer des solutions à base de J2EE WAS avec des EJB partout, avec parfois pour conséquence un coût d'administration hallucinant pour stabiliser une JVM qui explose en vol faute de mémoire ou que sais-je encore.

[Agnello Fabrice]

Je ne suis pas entièrement d'accord avec le fait que $_POST n'est pas plus sécurisé que $_GET. Le fait que $_GET passe par l'url permet de récupérer plus facilement les informations (je pense) que $_POST (ou du moins la difficulté pour le récupéré via un $_POST n'est pas à la porté de tous). Vous serez d'accord avec moi sur le fait qu'il est inconcevable de mettre en $_GET des informations de type mot de passe (surtout s'il y est crypté) ou login . Le "plus" n'est peut être pas très énorme mais il est quand même présent.

Je pense que la remarque de Benjamin se posait du côté serveur et sur les valeurs des données reçu par ce dernier.
je vous rejoins néanmoins, sur le point de l'envoi de données "sensibles" (login, password, etc.) en post plutôt qu'en get, mais de ce point de vue là, la sécurité passe aussi par l'emploi de l'https qui sécurise le transport.

[Retrokiller069]

Il reste tout de même qu'une autre légende urbaine veut que PHP soit cantonné aux sites perso/vitrine/whatever, mais ne convient pas pour des applications professionnelles type ERP ou métier.

Je pense qu'elle est venu à cause des évolutions rapides des navigateurs. Cela n'a aucun impacte sur le PHP, c'est vrai, mais plus sur l'interface, ce qui du coup à favoriser les autres langages. Je sais que ce fut le problème dans une entreprise d'ERP où j'avais effectué mon stage et que par souci de facilité, ils ont préféré passer sous FLEX pour ne plus avoir ce problème. Vous allez me dire "et alors ils auraient pu continuer à utiliser PHP", mais il est vrai aussi que dans ce genre de langage il privilégie d'autres types d’accès au serveur.

Je pense aussi que cela vient du fait que souvent PHP=WEB...

Je pense que la remarque de Benjamin se posait du côté serveur

Autant pour moi

[Benjamin Delespierre]

@Retrokiller069

Je ne suis pas entièrement d'accord avec le fait que $_POST n'est pas plus sécurisé que $_GET. Le fait que $_GET passe par l'url permet de récupérer plus facilement les informations (je pense) que $_POST (ou du moins la difficulté pour le récupéré via un $_POST n'est pas à la porté de tous). Vous serez d'accord avec moi sur le fait qu'il est inconcevable de mettre en $_GET des informations de type mot de passe (surtout s'il y est crypté) ou login . Le "plus" n'est peut être pas très énorme mais il est quand même présent.

Installe donc la webdevelopper toolbar et firebug pour Firefox et tu verra avec quelle facilité n'importe qui peut transformer les formulaires, le type des champs et les données POST avant envoi. Je maintiens ce que j'ai dit, l'idée que POST soit plus difficile à modifier que GET n'elève rien au fait que la sécurité de ces deux méthodes est strictement la même: faible.
Si vous concevez une application en supposant que le fait de mettre les données en POST les sécurise ne serait-ce qu'un peu, vous faites une énorme erreur.

@Agnelo Fabrice

Il reste tout de même qu'une autre légende urbaine veut que PHP soit cantonné aux sites perso/vitrine/whatever, mais ne convient pas pour des applications professionnelles type ERP ou métier. Là aussi c'est éminemment faux, mais ce mythe a la dent dure à tel point que les entreprises vont y préférer des solutions à base de J2EE WAS avec des EJB partout, avec parfois pour conséquence un coût d'administration hallucinant pour stabiliser une JVM qui explose en vol faute de mémoire ou que sais-je encore.

En effet, mais j'ai constaté également l'effet inverse qui à tendance - et c'est une bonne chose - a se démocratiser: la conversion ou refonte d'application Java en PHP. Ce qui peut s'expliquer selon moi par une réduction significative des coûts de développement / maintenance / exploitation beaucoup plus faibles qu'avec Java. Je pense que l'intégration de l'OOP en PHP n'y est pas non plus étrangère, ni la similitude entre le modèle objet de Java et celui de PHP.
Rappellons que le salaire moyen d'un développeur PHP est très largement en dessous de celui d'un développeur Java

@Retrokiller069
[QUOTE]Je pense aussi que cela vient du fait que souvent PHP=WEB.../QUOTE]
C'est vrai mais de plus en plus d'entreprises choisissent PHP pour des intranets ou des GUI - à commencer par la mienne.

[Agnello Fabrice]

Je pense qu'elle est venu à cause des évolutions rapides des navigateurs. Cela n'a aucun impacte sur le PHP, c'est vrai, mais plus sur l'interface, ce qui du coup à favoriser les autres langages.

Oui, des contraintes externes peuvent écarter PHP. Ce peut être le cas notamment si on veut rester cohérent avec l'ensemble d'un SI qui serait par exemple basé sur du Microsoft (.Net facilitera la mise en œuvre de toutes les couches de communication avec son écosystème environnant).

Je sais que ce fut le problème dans une entreprise d'ERP où j'avais effectué mon stage et que par souci de facilité, ils ont préféré passer sous FLEX pour ne plus avoir ce problème. Vous allez me dire "et alors ils auraient pu continuer à utiliser PHP", mais il est vrai aussi que dans ce genre de langage il privilégie d'autres types d’accès au serveur.

Dans ce cas précis, je trouve que PHP (mais je me fourvois peut-être, voire surement car mon expérience sur ce point précis date un peu maintenant) est un peu à la traine si on le compare aux deux autres technos mainstream (.Net et J2EE) sur l'exposition de WebServices.
Là où .Net et J2EE vont générer du WSDL tout seuls comme des grands à exposer aux clients divers, il faut se fader l'écriture du WSDL en PHP avec toutes les contraintes que cela implique.

Pour le front-end dictant le choix de la techno sous-jacente, là encore il peut y avoir un soucis de cohérence dans l'écosystème (ce qui est bon, ne serai-ce que par soucis de capitaliser sur le nombre de compétences internes ), mais on faisait du multi-canal bien avant que ces technologies de présentations riches n'émergent vraiment, mais si on expose des services web (wsdl, rest/json, ou autre) peu importe, on pourra plugger n'importe quel front-end sans même avoir à toucher le serveur.

Je pense aussi que cela vient du fait que souvent PHP=WEB...

C'est effectivement une bien belle casserole que nous avons là

@Benjamin => désolé, je crois que je me suis un peu écarté du sujet initial.

[Retrokiller069]

Installe donc la webdevelopper toolbar et firebug pour Firefox et tu verra avec quelle facilité n'importe qui peut transformer les formulaires, le type des champs et les données POST avant envoi. Je maintiens ce que j'ai dit, l'idée que POST soit plus difficile à modifier que GET n'elève rien au fait que la sécurité de ces deux méthodes est strictement la même: faible.
Si vous concevez une application en supposant que le fait de mettre les données en POST les sécurise ne serait-ce qu'un peu, vous faites une énorme erreur.

n'importe qui ne c'est pas utilisé webdevelopper toolbar et firebug. Je ne dis pas que ce n'est pas simple de récupérer des informations lorsque c'est un $_POST, il n'y a pas une grosse difficulté. Mais tu ne peux pas nier que c'est plus simple en methode Get que en méthode post? Leur sécurité sont faible mais je pense que la méthode Get est légèrement plus faible.

[Agnello Fabrice]

Rappellons que le salaire moyen d'un développeur PHP est très largement en dessous de celui d'un développeur Java

C'est, je crois, un des points majeurs qui peut faire basculer vers PHP. En terme de temps de développement (et uniquement ce poste là), avec des frameworks de chaque côté (Symfony/Doctrine en PHP et Struts2/Hibernate en J2EE par exemple), les temps sont AMHA équivalents.
Sauf que tout va se jouer sur le chiffre en bas à droite, qui prendra en compte les coûts de license, de compétences (administration, développement, encadrement, etc.) et de maintenance. Et là, PHP tire son épingle du jeu.

C'est vrai mais de plus en plus d'entreprises choisissent PHP pour des intranets ou des GUI - à commencer par la mienne.

Chez nous, pas encore en ce qui concerne les intranet, mais pour les applications métier que nous développons en interne, c'est PHP (et du java pour d'autres parties, comme certains webservice et processus d'extraction/réplication).

[Benjamin Delespierre]

@Agnello Fabrice

Chez nous, pas encore en ce qui concerne les intranet, mais pour les applications métier que nous développons en interne, c'est PHP (et du java pour d'autres parties, comme certains webservice et processus d'extraction/réplication).

Je suis sûr que vous pourriez tirer avantage des possibilités offertes par Quercus ou le PHP-Java bridge (dont une implem est disponible dans le langage désormais).

@Retrokiller069

Mais tu ne peux pas nier que c'est plus simple en methode Get que en méthode post?

Et après ? A partir du moment où c'est possible il suffit d'une seule personne pour que la sécurité de l'application soit compromise. Se dire "c'est pas si grave, personne aura l'idée de faire ça" est selon moi la pire erreur qu'un développeur consciencieux puisse faire. Donc pour moi la règle est de vérifier systématiquement tout ce qui provient de l'utilisateur et de la base de données.

[grunk]

Là où .Net et J2EE vont générer du WSDL tout seuls comme des grands à exposer aux clients divers, il faut se fader l'écriture du WSDL en PHP avec toutes les contraintes que cela implique.

C'est sans doute pour ça que l'on va privilégier un WS en REST si on le fait en PHP. Peut être que si SOAP est nécessaire c'est que PHP n'est plus l'outil idéal pour le webservice.

[Agnello Fabrice]

C'est sans doute pour ça que l'on va privilégier un WS en REST si on le fait en PHP. Peut être que si SOAP est nécessaire c'est que PHP n'est plus l'outil idéal pour le webservice.

Complètement d'accord avec vous.

Il reste que bien que verbeux à l'extrême, le SOAP a le bon goût d'offrir la possibilité de typer fortement et exhaustivement les données qui sont envoyées dans le tuyau et de fait peut être privilégié lors du choix d'une solution. Si la base installée est sur du *AMP par exemple, et qu'on choisi d'établir un canal de communication fortement décrit, SOAP s'imposera par rapport à REST.

Encore une fois, il me semble que l'écosystème dans son ensemble dicte aussi en partie le choix des technologies.

Dans tous les cas, il me semble comme Benjamin l'a évoqué plus tôt que PHP n'est plus persona non grata dans les entreprises et qu'il a acquis une certaine respectabilité (j'ai aussi, à tort, été un grand détracteur de ce langage dans une autre vie).

[Retrokiller069]

Donc pour moi la règle est de vérifier systématiquement tout ce qui provient de l'utilisateur et de la base de données.

Je suis entièrement d'accord mais il y a une légère différence entre les 2 quand même.

Aucune des 2 ne peut garantir une sécurité des données (ce que tu soulignes depuis tout à l'heure et que j'approuve totalement). Mais la méthode post possède une difficulté, certes minime mais présente, pour récupérer les données qui pourrait dire que celle-ci est légèrement plus fiable que le get.

Le fait de voir "index.php?idenfiant=1" est quand même moins sécurisé que le fait de voir "index.php" et de passé l'identifiant par méthode post. Même si je suis d'accord qu'un contrôle doit être fait lors de la réception de la variable.

Enfin tout ca pour dire que pour moi, la méthode post est plus sécurisé que la méthode get même si cette différence n'est pas énorme et qu'elle ne dispense pas d'effectuer des controles par la suite.

[ovh]

Dans ce cas précis, je trouve que PHP (mais je me fourvois peut-être, voire surement car mon expérience sur ce point précis date un peu maintenant) est un peu à la traine si on le compare aux deux autres technos mainstream (.Net et J2EE) sur l'exposition de WebServices.
Là où .Net et J2EE vont générer du WSDL tout seuls comme des grands à exposer aux clients divers, il faut se fader l'écriture du WSDL en PHP avec toutes les contraintes que cela implique.

Grâce aux frameworks, ce n'est plus le cas, le WSDL s'écrit tout seul aussi (en tout cas en Zend Framework je peux le certifier, je ne sais pas pour les autres)
http://framework.zend.com/manual/fr/...discovery.html