La vie est dure pour PHP.
Le 4 décembre était annoncé la sortie de la version stable PHP 5.2.7. Cette version était uniquement destinée à corriger des bugs et à stabiliser le logiciel.
Après 6 mois de dur travail par les développeurs du projet ces derniers pouvaient annoncer fièrement que plus de 170 bugs étaient corrigés dont de nombreux problèmes de sécurité !
Il est donc parfaitement normal que le site du projet ait encouragé les utilisateurs à télécharger cette version 5.2.7 : "All users of PHP are encouraged to upgrade to this release".
Hélas, trois fois hélas, cette nouvelle version s'est avéré contenir un horrible trou de sécurité qui n'était pas présent auparavant et les développeurs du projet ont été obligés de publier un communiqué demandant à leurs utilisateurs de ne plus télécharger la 5.2.7 et même de faire un downgrade vers la 5.2.6 !
On notera toutefois que ce bug n'affecte que les utilisateurs des "magic quotes" et qu'il faut donc réfléchir avant d'opter ou non pour un downgrade.
Journal N'installez pas PHP 5.2.7 !
8
déc.
2008
# d'un autre coté ...
Posté par Mouns (site web personnel) . Évalué à -7.
alors une plus ...
[^] # Re: d'un autre coté ...
Posté par sebbu (site web personnel, Mastodon) . Évalué à 1.
alors qu'elles ne savent pas car leur code ne vaux rien.
et puis les magic quote a toujours été une faille de sécurité,
surtout qu'il faut vérifier la valeur si tu change d'hébergeur ou si t'a pas la meme configuration en local...
et personne d'autre que les débutants utilisent les magic quote,
sinon tlm les désactive ou gère les différentes config en récupérant la config via ini_get ;)
pour les failles, suffit de voir le nombre d'exploits pour phpbb ou autres ;)
[^] # Re: d'un autre coté ...
Posté par jeffcom . Évalué à 10.
Les commentaires aussi
[^] # Re: d'un autre coté ...
Posté par Mouns (site web personnel) . Évalué à 2.
sur http://fr.php.net/magic_quotes site officiel de PHP :
Cette fonctionnalité est OBSOLETE et a été supprimée depuis PHP 6.0.0. Nous vous encourageons vivement à ne pas l'utiliser.
[^] # Re: d'un autre coté ...
Posté par jeffcom . Évalué à 10.
non ? Ça t'étonnes ? sérieux ?
sur http://fr.php.net/magic_quotes site officiel de PHP :
Cette fonctionnalité est OBSOLETE et a été supprimée depuis PHP 6.0.0. Nous vous encourageons vivement à ne pas l'utiliser.
Sans déconner ?... je crois que cette annonce est là depuis que PHP 6 est en alpha soit... un petit moment déjà, et avant ça, (depuis PHP5 je crois, donc encore plus longtemps) une annonce du même type indiquait le coté bancale de cette fonctionnalité et, avant ça encore, de nombreux commentaires (qui se trouvent en bas de chaque page de doc sur php.net) informaient de tout cela... donc en gros, même si quelqu'un s'est "auto-formé", s'il est passé sur la page, (chose quasi certaine tant les avertissements concernant les magic_quotes sont omniprésents dans chaque projet un tant soit peu sérieux et ailleurs sur le net) il(elle) aura vu que ça n'était clairement pas une bonne chose.
L'histoire du magic_quote c'est un peu comme le register_globals, c'est du connu depuis belle lurette...
Il es clair aussi que PHP se traîne quelques boulets pour rétro-compatibilité... mais il faut comprendre d'où viens php et en combien de temps il a évolué, comment, et vers où il va.
PHP5 préparait à l'arrivée de PHP6 tout en permettant un maximum de rétro-compatibilité avec les versions précédentes (un peu comme avec les versions 2.5, 2.6 et 3 de python)
Donc, oui, on sait, ya des boulets, on est au courant... mais dire "php c'est de la merde parce que des devs pissent du code" désolé, mais ça mérite bien une telle note... on peut pisser du code, quel que soit le langage, et tout système a ses failles, ça veut pas forcément dire que c'est le mal absolu... ou que tout ce qu'on produira avec sera de la merde
[^] # Re: d'un autre coté ...
Posté par tcheuck . Évalué à 5.
On peut coder très proprement en POO avec PHP5. Ce qui fait la mauvaise réputions de PHP c'est toutes ces personnes qui ne savent pas coder en respectant certains principes ...malheureusement une majorité des utilisateurs de PHP, du fait de la très grande "tolérance" du language.
[^] # Re: d'un autre coté ...
Posté par libre Cuauhtémoc . Évalué à 4.
" LE problème des failles ne vient pas de php, mais de l'usage qui en est fait"
[^] # Re: d'un autre coté ...
Posté par jeffcom . Évalué à 5.
[^] # Re: d'un autre coté ...
Posté par Gniarf . Évalué à 0.
[^] # Re: d'un autre coté ...
Posté par thedude . Évalué à 4.
L'erreur est humaine, et statistiquement, meme le meilleur codeur fera un jour une connerie, c'est meme pour ca qu'on a invente la machine, parce qu'elle, des erreurs, elle en fait pas.
J'ai du mal a comprendre comment on peut ecrire un gros projet dans un langage interprete, se passe de la detection d'erreur de la compilation, le tout sans serrer les fesses, la goutte de sueur au front, au moment de deployer l'application en priant pour que tout le code ait effectivement ete teste et qu'on va pas avoir une partie qui va nous peter a la gueule en prod.
[^] # Re: d'un autre coté ...
Posté par jeffcom . Évalué à 2.
T'es sérieux là ? comment il va s'exécuter ton code s'il est pas compilé ? :)
D'ailleurs, PHP a plusieurs étapes¹ de compilation qu'on peut résumer très rapidement (et de tête) en
- précompilation (qui inclue les vérifications du code lui même comme la syntaxe, le type de données passées aux fonctions et commandes)
- analyse et optimisation du code précompilé
- compilation et création de l'opcode²
donc il y a de la détection d'erreurs, et php sait être très verbeux quand on le configure pour.
de plus il existe des choses comme PHPUnit qui permettent d'aller très loin coté audit de code.
Oui on peut faire du super-goret, de l'immonde, du grand n'importe quoi en PHP, mais on peut aussi avoir un code d'une très grande lisibilité, d'une grande modularité et d'une grande efficacité : tous les outils (sans parler des frameworks) et les méthodes existent pour se faire.
¹ le tout effectué par le Zend_Engine qui effectue ce travail depuis php3 (la première version du PHP que nous connaissons aujourd'hui) où il était en version 0.5 (php4 utilise la 1 et php5 la 2, qui est, de très loin, la plus rapide, complète et fiable)
² cet opcode peut, d'ailleurs, être mis en cache et réutilisé lors d'un appel ultérieur du script, ainsi on a un gain de temps considérable et des perfs vraiment boostées, sans sacrifier au coté dynamique que n'offre pas un cache statique qui, lui, oblige à avoir une version figée (pas dynamique) durant un certain temps.
[^] # Re: d'un autre coté ...
Posté par TImaniac (site web personnel) . Évalué à 3.
Je penses qu'il parlait de compilation "statique", tu sais quand ca pète sur le poste du dev plutôt que sur le serveur de prod.
[^] # Re: d'un autre coté ...
Posté par jeffcom . Évalué à 2.
Dans tous les cas, le dev qui sort une appli et qui la met en prod direct sans tests, un gros boulet incompétent. Le dev un tant soit peu cérébré, lui, va s'installer un environnement de dev, soit sur sa propre machine, soit sur un autre serveur (de dev) et testera son appli à fond avant de mettre en prod... bref il va tester avant de mettre en prod...
L'interprété c'est comme le compilé, ça répond aux mêmes règles de développement ! (je vois pas bien pourquoi ça serait autrement d'ailleurs) la seule différence, c'est que l'interprété, on a pas à modifier le code en fonction de la plateforme (ou presque) ni à passer des heures de compilation pour s'apercevoir que l'appli merde : on peut tester les scripts un à un, ce qui améliore considérablement la qualité du travail.
En passant, il est tout à fait possible de créer un exécutable directement écrit en un langage interprété...
[^] # Re: d'un autre coté ...
Posté par thedude . Évalué à 3.
et puis quand ça pète, soit ça "plante" (fatal error : ie ça s'exécute même pas), soit ça affiche des warnings (là ça s'exécute mais pas forcément bien) soit ça affiche rien (par défaut, l'utilisateur peut créer ses propres exceptions) et là charge au dev de voir si le soft fait bien ce qui était prévu...
Ok.
En somme, quand ca pete, soit ca fait qq chose, soit ca fait rien?
He be, ca c'est un bel avantage, faut croire que le code interprete qui pete le fait plus proprement que du compile.
Tant tous les cas, ca pete, donc bon, on s'en fout un peu que ca affiche des warnings ou que ca se bourre lamentablement.
L'interprété c'est comme le compilé, ça répond aux mêmes règles de développement ! (je vois pas bien pourquoi ça serait autrement d'ailleurs)
Non, le test du code doit etre bien plus exhaustif, car tu dois toi meme tester ce que le compilo teste.
Bref, oui, on peut avoir la meme qualite de code avec de l'interprete, mais c'est plus dur.
Et encore, faut etre super confiant dans ses tests.
la seule différence, c'est que l'interprété, on a pas à modifier le code en fonction de la plateforme (ou presque)
Ouch. Java, .Net, ca te parle?
Un code, un binaire et ca passe partout (modulo les libs pur MS pour .Net).
Le problemes de portabilite sont strictement les memes (link a lib native ou path pour un fichier).
Et du code portable, ca peut s'ecrire meme en c/c++ (ok, on parlait de code serveur la, donc je sort du sujet un peu).
ni à passer des heures de compilation pour s'apercevoir que l'appli merde
Eclipse fait de la compile a la volee. Le temps de compile de mon projet est donc quasi nul. Tous les interprete n'ayant pas forcement pas de cache de bytecode, je pense meme qu'au final, on perd moins de temps a recompiler sans cesse a l'executio. Dans les 2 cas, on ne le sent pas de toutes facons.
: on peut tester les scripts un à un, ce qui améliore considérablement la qualité du travail.
Ca s'appelle un test unitaire, et pour qq1 qui donne des lecons sur la qualite du code, tu devrais savoir que c'est qq chose de tres tres fortement recomande pour tous les projets de toutes facons (et une condition necessaire mais non suffisante pour s'assurer de la qualite du produit).
[^] # Re: d'un autre coté ...
Posté par jeffcom . Évalué à 2.
Bah apparemment ya des gens qui n'y connaissent vraiment rien donc je survole de très haut pour expliquer et que tout le monde comprenne... j'ai sûrement été trop rapide... et je ne suis pas intégriste non plus, simplement je ne comprends pas pourquoi ce haro totalement infondé sur le langage interprété...
En somme, quand ca pete, [...], on s'en fout un peu que ca affiche des warnings ou que ca se bourre lamentablement.
perso je m'en fout pas... au moins je sais que les autres services hébergés du serveur sont ok et que toute les ressources de la machine ne seront pas consumées par un pov script... (puisque les accès mémoire etc sont gérés par autre chose que mon script, et que le temps maxi d'exécution peut être fixé, de même que la taille max de mémoire (entre autes choses).
Donc non, on s'en fout pas : en cas de soucis, ça permet de pas mettre en péril toute la machine.
Après c'est sûr que si tu fais tomber toutes ces barrières ou que tu exécutes directement ton script php par php en root... je peux rien pour toi...
Non, le test du code doit etre bien plus exhaustif, car tu dois toi meme tester ce que le compilo teste.
waw tester ce que le compilo teste... joli :)
Bref, oui, on peut avoir la meme qualite de code avec de l'interprete, mais c'est plus dur.
Et encore, faut etre super confiant dans ses tests.
Je vois pas bien en quoi c'est plus dur... si tu as de la méthode et que tu sais ce que tu fais... ça devrait pas être plus dur.. après c'est certain que si tu as l'habitude de faire du goret et que seuls les tests te permettent de faire du code de qualité...
De plus, comme je le disais plus haut (ou ailleurs je sais plus) : c'est compilé, si non comment l'exécuter ? alors, certes, selon le langage, certaines erreurs passent la compilation, et le script peut être exécuté même s'il comporte des erreurs sémantiques ou de typage mais rien de dramatique : pour php, par exemple, au pire t'auras un warning, dans python t'auras un beau message d'erreur de compilation... ah... comme avec un "vrai" compilateur dis donc ! c'est fou quand même !
Ouch. Java, .Net, ca te parle?[...](ok, on parlait de code serveur la, donc je sort du sujet un peu).
sauf qu'il n'y a *jamais* besoin de toucher au code pour prendre en charge telle ou telle archi. Il faut simplement prendre en compte les spécificités ponctuelles de certains OS lors de l'utilisation de certaines fonctions (exemple : penser au flag "b" pour que les fichiers soient ouverts en binaire au lieu de ascii sous Win si on utilise "fopen") on est simplement conditionné à l'existence d'un portage de l'interpréteur sur l'archi cible...
En C par exemple, selon le compilateur utilisé, on va obtenir ou non une compilation, on va pas avoir les mêmes messages d'erreur, pas les mêmes warnings, pas les mêmes comportements, en plus de devoir prendre parfois en compte l'archi et la plateforme cible...
par exemple, j'ai toujours eu du mal à compiler ffmpeg... le problème ne viens pas de mon archi ou des dépendances, mais du compilo et de son paramétrage... aucun souci avec un langage interprété : si l'interpréteur et les deps sont présentes : ça se lance à tous les coups.
et, oui : java, .Net (beurk), etc. ça me parle...
Eclipse fait de la compile a la volee.
Tout le monde n'utilise/ne peut pas utiliser Eclipse...
Ca s'appelle un test unitaire
Moi je le sais, mais c'est pas certain que les autres lecteurs le sachent...
et pour qq1 qui donne des lecons sur la qualite du code
Je ne voulais pas donner des leçons mais contrer le troll qui dit que "PHP saimal parce que c'est permissif et que l'interprété saipareil parce que c'est pas compilé"
tu devrais savoir que c'est qq chose de tres tres fortement recomande pour tous les projets de toutes facons (et une condition necessaire mais non suffisante pour s'assurer de la qualite du produit).
oui, c'est pour ça que j'en ai parlé... pour quelqu'un qui réponds avec virulence tu devrais *tout* lire avant de répondre...
Conclusion :
on est tous les deux d'accord... le problème c'est que toi (et d'autres) ne semblent pas connaître suffisamment php et les autres langages interprétés pour avoir un avis vraiment impartial ou simplement prendre du recul : tout n'est pas tout rose et parfait, mais il y a tout ce qu'il faut pour faire un code très clean et avec un minimum de rigueur on s'en sort très bien
Il ne faut pas oublier, au passage, qu'on ne va pas faire la même chose en C ou en php...
Les comparaisons sont donc un peu capillo-tractées....
[^] # Re: d'un autre coté ...
Posté par TImaniac (site web personnel) . Évalué à 2.
En l'interprétant ! C'est la 2ème façon d'exécuter du code dis donc :)
our php, par exemple, au pire t'auras un warning, dans python t'auras un beau message d'erreur de compilation... ah... comme avec un "vrai" compilateur dis donc ! c'est fou quand même !
Oué bah je préfères avoir l'erreur sur un poste de développeur ou un serveur de build.
sauf qu'il n'y a *jamais* besoin de toucher au code pour prendre en charge telle ou telle archi.
Comme .NET et Java, qui sont compilés et font abstraction de l'architecture matérielle/OS sous jacent.
et, oui : java, .Net (beurk), etc. ça me parle...
On dirait pas puisque tu comprends pas.
Tout le monde n'utilise/ne peut pas utiliser Eclipse...
Ceux qui font du Java utilise Eclipse, ceux qui font du C# utilisent Visual, dans tous les cas le temps de compilation est anecdotique, donc le temps de compilation n'est PAS un problème.
PHP saimal parce que c'est permissif et que l'interprété saipareil parce que c'est pas compilé
C'est pas tout à fait exact. Ce qu'il faudrait plutôt dire : les langages dynamiques à la sémantique laxistes saimal. Après le fait est que ces langages sont généralement non compilés car non compilable.
On est pas du tout d'accord. On peut tout à fait produire du code de qualité en PHP. Seulement le coût est bien plus important qu'avec un langage à la sémantique plus strict, au typage statique, avec vérifications de tout ca à la compilation.
Après dire que beaucoup de développeurs professionnels sont contraints de faire un choix entre "temps" et "qualité", il n'y a qu'un pas... L'avantage du langage compilé avec typage statique et strict, c'est que c'est un passage obligé avant la mise en prod, alors qu'en PHP t'as toujours le choix de pas faire suffisament de tests...
Sérieusement t'as déjà fait des stats de couverture de code de tests U ? T'as déjà obtenu plus de 90% de code ? Le boulot pour arriver à une telle couverture de code est énorme, quelque part tu avoues qu'une partie du code n'est pas testé, alors t'imagine sans langage typé statiquement et vérifié par un compilo les dégâts potentiels...
[^] # Re: d'un autre coté ...
Posté par jeffcom . Évalué à 2.
et l'interpréteur, il produit quoi ? un code à interpréter par un autre interpréteur ? ou un code (plus ou moins) compilé ? (ces questions n'appellent pas de réponse de ta part, si non tu vas re-poster un lien vers Wikipedia)
Oué bah je préfères avoir l'erreur sur un poste de développeur ou un serveur de build.
justement, c'est là qu'elles doivent apparaître les erreurs,.. (cf autres posts où je dis qu'il faut être un peu boulet pour balancer n'importe quoi sur un serveur de prod)
Ceux qui font du Java utilise Eclipse, ceux qui font du C# utilisent Visual, dans tous les cas le temps de compilation est anecdotique, donc le temps de compilation n'est PAS un problème.
Il n'y a pas que Java et C# dans la vie... perso quand je compile ffmpeg, ça prends souvent plus d'une heure... (petite machine) la compilation est un problème dans ce cas... et tout le monde n'utilise pas java/Eclipse et C#/Visual... enlève tes œillères
Ce qu'il faudrait [...] dire : les langages dynamiques à la sémantique laxistes saimal.
C'est pas parce que ça permet certaines choses qu'il ne faut faire que ça. Sur la route, parfois il n'y a ni ligne continue au sol, ni flèches indiquant le sens de circulation, ni gendarme : c'est pas pour autant qu'il faut rouler à gauche à tombeau ouvert avec 3g.
Après le fait est que ces langages sont généralement non compilés car non compilable.
non compilables ? intéressent...
en PHP t'as toujours le choix de pas faire suffisament de tests
Tu as aussi le choix d'ignorer les warnings du compilateur et même de ne pas faire de tests unitaires sur ton code compilé... et de balancer en prod...
Sérieusement t'as déjà fait des stats de couverture de code de tests U ?
ça appelait une réponse ?
le boulot pour arriver à une telle couverture de code est énorme
[[Méthodologie]] tu connais ?
développer, ça s'improvise pas... (même si on peut improviser) c'est clair que si tu pisses du code, tu va avoir pas mal de travail pour l'auditer alors que si, dès le départ, tu réfléchis à ce que tu fais, que tu découpes ton code en modules fonctionnels, que tu le commentes, etc... il devient plutôt facile de faire quelque chose de très (plus) facilement auditable.
quelque part tu avoues qu'une partie du code n'est pas testé
si je pisse du code oui, c'est certain, mais c'est pareil avec un langage compilé...
d'un autre coté même avec un langage compilé tu ne pourras pas vraiment être certain de 100% de ton code.
Enfin, encore une fois, je ne m'amuse pas à faire de la compression vidéo en php, et je ne m'amuse pas à faire un forum en C#... ça n'est pas vraiment comparable
[^] # Re: d'un autre coté ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Faudra que t'écrives un interpréteur un jour, tu comprendras la différence. En gros y'a pas d'étape où tu traduis le code original en code machine : tu exécutes un code (qui est dans l'interpreteur) qui correspond à la sémantique du code original.
justement, c'est là qu'elles doivent apparaître les erreurs,..
tu te fou de moi ? On parlait d'un problème qui arrivait sur un serveur de prod parcque justement passé inaperçu...
Il n'y a pas que Java et C# dans la vie... perso quand je compile ffmpeg, ça prends souvent plus d'une heure...
Rattrapes toi aux branches. On parle de PHP et donc de ce qui est comparable. C# et Java sont 2 langages compilés qui visent (entre autre) le même types d'application web que PHP.
Donc laissons le C et ffmpeg de côté.
Sur la route, parfois il n'y a ni ligne continue au sol, ni flèches indiquant le sens de circulation, ni gendarme : c'est pas pour autant qu'il faut rouler à gauche à tombeau ouvert avec 3g.
Quand t'es pressé, c'est tentant de dépasser les limites de vitesse. Quand ta voiture est bridé, c'est quand même plus difficile.
Tu as aussi le choix d'ignorer les warnings du compilateur et même de ne pas faire de tests unitaires sur ton code compilé... et de balancer en prod...
Tu réponds à côté de la plaque. Je disais justement que l'avantage d'un langage compilé, c'est qu'il y a un "gendarme", dans tous les cas. Ta remarques s'appliques très bien à PHP de la même manière et ne répond pas à ma remarque.
ça appelait une réponse ?
ben je sais pas, t'as l'air de croire qu'il est super facile de tester avec des tests U tout ce que peut vérifier un compilateur...
développer, ça s'improvise pas... (même si on peut improviser) c'est clair que si tu pisses du code, tu va avoir pas mal de travail pour l'auditer alors que si, dès le départ, tu réfléchis à ce que tu fais, que tu découpes ton code en modules fonctionnels, que tu le commentes, etc... il devient plutôt facile de faire quelque chose de très (plus) facilement auditable.
Mais ca n'empêche que le développeur il est pas infaillible, il peut faire une erreur, ou tu peux avoir besoin de faire du refactoring, et étant donné que t'as pas une couverture à 100% de ton code en test U, tu peux laisser une erreur ou 2 par ci par là, bref, tu peux faire tous les audits que tu veux, ca remplacera jamais ton compilateur qui comme dirait vient comme une sécurité "gratuite" supplémentaire. Continuer à prétendre que cette sécurité gratuite est totalement remplacable par des méthodes (audit, testU & co) est vraiment malhonnête quand tout le monde sait que les 2 sont complémentaires et non redondant.
si je pisse du code oui, c'est certain, mais c'est pareil avec un langage compilé...
Raaaah mais le compilo il va quand même éviter un certain nombre de conneries !
a = null
a.test()
moi mon compilo il va direct gueuler. Toi tu vas devoir écrire un test U pour ca, tu vas devoir faire un audit, sans aucune garantie au passage que tu vas effectivement tester ce cas. Quel est le plus coûteux ?
Le compilo c'est un automate, relativement fiable, qui coûte quasiment rien, pourquoi s'en passer je te le demande ?
Enfin, encore une fois, je ne m'amuse pas à faire de la compression vidéo en php, et je ne m'amuse pas à faire un forum en C#... ça n'est pas vraiment comparable
Tu avoues ton ignorance total de C# : c'est un langage qui dès le début à été conçu pour être entre utilisé pour réaliser des applis web dynamique, et qui est utilisé pour dans la réalité.
[^] # Re: d'un autre coté ...
Posté par Mouns (site web personnel) . Évalué à 3.
depuis quand utiliser un compilo ca protège des failles de sécurité et des problèmes ?
nan parce que si c'est vrai, comment Debian a réussi à pondre une faille là où il n'y en avait pas, dans OpenSSL ?
A chaque manière de programmer ses problemes.
les langages compilés ont leurs lots de merdes.
les langages interpretés en règlent certains mais en apportent d'autres.
[^] # Re: d'un autre coté ...
Posté par TImaniac (site web personnel) . Évalué à 3.
Cela dit c'est un outil qui permet d'éviter un grand nombre de problème, c'est un outil comme un autre qui aide à l'amélioration de la qualité d'un soft.
Evidemment qu'il n'est pas une garantie, qu'on peut coder crade avec un compilo et coder propre avec un interpréteur, mais le compilo reste tout de même un garde fou qui participe à la qualité du code produit.
La grammaire et la sémantique d'un langage va souvent de pair et constitue également un autre élément aidant à produire du code de meilleur qualité (là encore y'a pas de garantie).
les langages interpretés en règlent certains mais en apportent d'autres.
M'étonnerait que ca apporte des merdes niveau qualité du code pondu, ce dont on parle.
[^] # Re: d'un autre coté ...
Posté par jeffcom . Évalué à 2.
Je rectifiait simplement ces postulats, tous évidement faux... soit :
- un langage interprété va être, de toute manières, compilé avant exécution
- on ne balance pas n'imp sur un serveur de prod, de la même manière qu'on n'envoie pas un soft qui a seulement été compilé (et pas testé, et dont les retours du compilo n'ont pas été analysés) au client
- qu'on dispose de pas mal d'outils d'audit de code qui sont plus efficaces qu'une sortie de compilo combinée à des heures d'arrachage de tifs pour comprendre où optimiser le code et comment.
Je n'ai *pas* dit que :
- ça protégeait d'une quelconque faille : c'est logique
- ça permettait d'avoir *forcément* un meilleur code : là encore, c'est logique
Après, c'est certain, tout dépend du gus qui code : on peut tout faire, tout voir....
[^] # Re: d'un autre coté ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Alors je vais moi aussi jouer sur les mots, ton postulat est faux.
Un langage interprété n'est pas compilé.
http://fr.wikipedia.org/wiki/Interpr%C3%A8te_(informatique)
Il y a bien au final exécution de code machine, mais le processus n'est pas le même, et les opérations de compilation et interprétation désigne bien 2 processus différents pour arriver au même résultat.
on ne balance pas n'imp sur un serveur de prod, de la même manière qu'on n'envoie pas un soft qui a seulement été compilé
Ce qu'à juste voulu dire le monsieur, c'est qu'un compilo effectue un grand nombre de vérification qu'il est irréaliste d'effectuer avec des tests unitaires. Donc si tu prends 2 programmes écrits dans 2 langages "proches" (voir identique) dont l'un est interprété et l'autre compilé, avec le même niveau de couverture de code niveau tests U, celui qui est compilé reste plus "sûr".
qu'on dispose de pas mal d'outils d'audit de code qui sont plus efficaces qu'une sortie de compilo combinée à des heures d'arrachage de tifs pour comprendre où optimiser le code et comment.
N'importe quoi. C'est pas plus ou moins efficace. C'est complémentaire. Et les avantages des 2 s'additionnent. Se passer de l'un des 2 va forcement avoir des implications.
[^] # Re: d'un autre coté ...
Posté par jeffcom . Évalué à 2.
Logique, si non ça s'appellerait "langage compilé"...
Mais il l'est dans une certaine mesure. Certes cette compilation est moins complète que celle d'un langage compilé (c'est logique, ça prendrais un temps fou une compilation complète et stricte à chaque appel...) mais dans la mesure où la gestion de la mémoire est gérée par l'interpréteur, de même que les accès disque et système, et que, dans le cas de php, on a pas de typage strict ni de déclaration des variables : ça n'est pas "grave"
Après le débat est tout autre (strict mieux que pas strict toussa...)
Le fait est que, même si le processus n'aboutit pas au même résultat, il y a compilation, en tout cas un mécanisme qui s'y apparente.
en gros :
→ je pond mon appli en C : je tente de compiler, j'ai des erreurs, des warnings... en cas d'erreur, ça compile pas, en cas de warning, ça compile.
→ je pond mon appli en php : je lance le script, j'ai des erreurs, des warnings... en cas d'erreur, ça se lancera pas, en cas de warning ça se lance...
\o/
Donc si tu prends 2 programmes écrits dans 2 langages "proches" (voir identique) dont l'un est interprété et l'autre compilé, avec le même niveau de couverture de code niveau tests U, celui qui est compilé reste plus "sûr"
ça aussi, c'est logique, mais on va pas faire la même appli en c et en php... il y a une notion de contraintes qu'il faut prendre en compte
Se passer de l'un des 2 va forcement avoir des implications.
C'est certain m'enfin tu ne m'as pas compris je pense... et je ne t'expliquerai pas : j'abandonne, ta rigidité d'esprit a eu raison de moi...
Ps : rassures-moi, tu n'a pas généré ton cv sur ton site web en C j'espère...
[^] # Re: d'un autre coté ...
Posté par thedude . Évalué à 2.
→ je pond mon appli en C : je tente de compiler, j'ai des erreurs, des warnings... en cas d'erreur, ça compile pas, en cas de warning, ça compile.
→ je pond mon appli en php : je lance le script, j'ai des erreurs, des warnings... en cas d'erreur, ça se lancera pas, en cas de warning ça se lance...
\o/
Oui, on se doute bien qu'un code syntaxiquement/semantiquement invalide ne va pas s'executer...
Tout comme du code machine inexecutable ne s'executera pas, t'auras ton erreur, et paf.
Ca nous avance pas tellement ton histoire la.
Maintenant, la difference, c'est que ton erreur/warning, en interprete, tu n'as aucun moyen de la detecter avant d'executer le bout de code en question.
Et des tests de couverture de code ecrit manuellement, c'est lourd et difficile a ecrire.
mais dans la mesure où la gestion de la mémoire est gérée par l'interpréteur, de même que les accès disque et système, et que, dans le cas de php, on a pas de typage strict ni de déclaration des variables : ça n'est pas "grave"
Tu sais, avec une VM, ta gestion de la memoire, les acces disque et tout le tralala, c'est gere par la VM, on est dans le meme cas.
D'ailleurs je vois pas en quoi c'est pas grave, ton code est errone, c'est ca qui est grave, fondamentalement.
La facon de rattraper les erreurs, meme si elle peut etre appreciable, reste accessoire.
ça aussi, c'est logique, mais on va pas faire la même appli en c et en php... il y a une notion de contraintes qu'il faut prendre en compte
Non, c'est sur.
Apres, en Java et en php, tu peux faire la meme appli. Et yen a une qui donnera moins de cheveux blancs aux devs (ou moins de boulot, c'est selon, mais comme l'a dit timaniac, on a pas toujours le choix des delais de developpement/test) a la mise en prod.
Des tests unitaires, ca prend deja pas mal de temps (en l'occurence, a peu pres autant de code de test que de code normal).
Si en plus tu dois te rajouter des tests a la con du genre "verifier le type de retour de la fonction", tu t'en sort plus.
[^] # Re: d'un autre coté ...
Posté par jeffcom . Évalué à 2.
Tout comme du code machine inexecutable ne s'executera pas, t'auras ton erreur, et paf.
On se doute mais Timaniac (et quelques autres) ne semblent pas l'avoir compris...
Ca nous avance pas tellement ton histoire la.
ben si, je reformulais quelquechose qui ne semblait pas logique pour certains...
Maintenant, la difference, c'est que ton erreur/warning, en interprete, tu n'as aucun moyen de la detecter avant d'executer le bout de code en question.
et ? c'est quoi le problème ? c'est pour ça que les environnements de dev existent !
Et des tests de couverture de code ecrit manuellement, c'est lourd et difficile a ecrire.
"Suffit" de pas coder avec les pieds, et de commenter ton code (avoir un codex à coté peut être un plus) et adopter des conventions de codage te permet de coder plus vite, mieux, de manière plus lisible, et de ne pas vraiment avoir besoin de tests de couverture de code écrits manuellement... bref faut avoir un minimum de méthodologie
on a pas toujours le choix des delais de developpement/test
là encore, la méthode permet d'avoir moins de cheveux blancs, car en cas de soucis, on arrive plus facilement à voir d'où ça viens, si tant est qu'un soucis arrive puisqu'on a utilisé une méthode de travail qui permet de réduire ce genre de risque.
Si en plus tu dois te rajouter des tests a la con du genre "verifier le type de retour de la fonction", tu t'en sort plus.
bah d'une part t'as pas vraiment à le vérifier (pour php du moins) puisque c'est dynamique et que les fonctions font avec. et, là encore, faut être cohérent dans son processus de dev... avant de donner une variable à une fonction attendant un tableau, il convient de vérifier qu'on lui donne bien un tableau... bref un seul mot d'ordre : méthode
[^] # Re: d'un autre coté ...
Posté par thedude . Évalué à 2.
Ouais, c'est comme les bugs.
"Suffit" de pas les ecrire, les bugs.
En codant avec les mains et pas les pieds, avec methodologie, une palanquee de tests, c'est facile d'eviter les bugs.
Sauf qu'on sait tres bien que ya des portions du code qui vont passer au travers de la methodologie, de l'attention etc, c'est meme pour ca qu'on a des bugs dans toutes les applis.
Ben pour l'interprete, c'est pareil, c'est plus de boulot, et au final, tu ne couvrira jamais tout.
C'est marrant quand meme.
On te dit "c'est lourd, c'est plus de boulot, faut faire gaffe a ce que tu fais, etre tres methodique et rigoureux, prendre plus de temps", et tu nous reponds "ouais, mais heu non c'est pas vrai, regarde, tu fais ca en plus. Pis ca et ca, pis si t'es methodique et rigoureux, tu t'en sort".
[^] # Re: d'un autre coté ...
Posté par jeffcom . Évalué à 2.
Mon discours était simplement de dire que pour l'interprété c'était pareil, mais comme le compilo est moins strict, la méthode et la rigueur dans le code permettait de palier à ça et que c'était en amont du compilo/interpréteur que le problème se situait réellement.
Comme quoi chacun comprends ce qu'il veut...
[^] # Re: d'un autre coté ...
Posté par TImaniac (site web personnel) . Évalué à 2.
L'erreur est humaine, t'as oublié ? Ben les bugs aussi dis donc ! Même avec toute la méthodologie du monde !
[^] # Re: d'un autre coté ...
Posté par jeffcom . Évalué à 2.
[^] # Re: d'un autre coté ...
Posté par TImaniac (site web personnel) . Évalué à 2.
exemples .NET : myspace.com, dell.com, match.com, monster.com
exemples Java : ebay.com, linkedin.com, hi5.com
Comme quoi dis donc c'est fait pour faire des sites web, comme PHP !
Après de là en conclure que t'y connais rien dans ces technos en affirmant que les usages sont diamétralement opposés...
[^] # Re: d'un autre coté ...
Posté par jeffcom . Évalué à 2.
Concernant : .Net, c'est de l'asp (voir Active_server_pages) qui est utilisé et qui peut, entre autres, encapsuler du .Net, du VBScript ou Jscript et autres joyeusetés made by MS
Concernant java, c'est du jsp(/JavaServer_Pages), donc oui, le langage est le même, mais, pour le coup, est interprété...
Évidement on peut, aussi, créer son site web en C... il suffirait de prendre lighttpd et lui inclure les pages (voire le cms) directement dedans. le gain de rapidité serait pour le coup plus que fulgurant... m'enfin on conviendra facilement que c'est un peu tuer une mouche à coup de blaster laser
Après, de là à en conclure que t'as loupé un épisode...
[^] # Re: d'un autre coté ...
Posté par TImaniac (site web personnel) . Évalué à 2.
tu postes des liens wikipedia qui prouve juste que t'y connais rien une fois de plus.
ASP, c'est vieux et révolu. Ta recherche google t'as induis en erreur, et la politique de nommage de Microsoft sans doute également.
dans .NET, la techno web s'appelle ASP.NET et n'a plus rien à voir techniquement avec ASP : http://fr.wikipedia.org/wiki/ASP.NET
T'aurais pris la peine de lire le lien que tu m'a pointé, c'était pourtant précisé à la fin.
Et j'en fais régulièrement au taf, alors t'es gentil tu vas pas me montrer ce que c'est. Et je peux te garantir qu'on écrit du C# pour faire du site web, et que je peux compiler mon bouzin avant de le mettre en prod.
Concernant java, c'est du jsp(/JavaServer_Pages), donc oui, le langage est le même, mais, pour le coup, est interprété...
Mais t'es vraiment trop marrant toi, tu me pointes un lien où c'est écrit noir sur blanc :
Les JSP sont compilées par un compilateur JSP pour devenir des servlets Java.
La référence à l'interprétation concerne le pseudo-code Java, autrement dit, le bytecode. Pour ta connaissance vu que tu n'y connais rien, y'a 2 étages de "traduction" :
fichier.java => compilation avec javac => java.class (bytecode).
Après ce bytecode peut être interprété ou compilé à la volée (technique JIT), la VM de Sun faisant plus ou moins un mix des 2 techniques.
Dans tous les cas le langage écrit par le développeur, c'est le .java, et lui est bel et bien compilé avec toutes les vérifications qui vont avec. Bref, on s'intéresse au premier étage.
m'enfin on conviendra facilement que c'est un peu tuer une mouche à coup de blaster laser
C'est pour ca que personne ne code de site web en C (ou presque), et que je ne comprends même pas pourquoi tu en parles.
[^] # Re: d'un autre coté ...
Posté par TImaniac (site web personnel) . Évalué à 2.
phpnuke => http://www.dotnetnuke.com/
wordpress => http://www.umbraco.org/ http://www.mojoportal.com/
http://en.wikipedia.org/wiki/ASP.NET#Performance
[^] # Re: d'un autre coté ...
Posté par jeffcom . Évalué à 2.
[^] # Re: d'un autre coté ...
Posté par TImaniac (site web personnel) . Évalué à 2.
http://pascalfresnay.free.fr/pub/website.png
[^] # Re: d'un autre coté ...
Posté par thedude . Évalué à 2.
Ca s'appelle une archi n-tiers (generalement 3 tiers : couche metier, couche db et couche presentation) et c'est le b.a-ba de la programmation web.
Pour quelqu'un qui parlait de separation en module fonctionnel, ca fait bizarre quand meme.
# D'aiSécurité des magic quotes ?
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Il est possible d'injecter du SQL sans apostrophe grâce à la syntaxe 0x... pour noter les chaînes des caractères : LOAD_FILE(0x2F6574632F706173737764) lit le contenu du fichier /etc/passwd et ne contient pas d'apostrophe. De plus, cette protection a introduit une autre faille avec le charset Big5 (utilisé pour le mandarin) : la séquence d'octets (0xB3, 0x27) est échappée en (0xB3, 0x5C, 0x27), or 0xB35C est un caractère valide en Big5, et on obtient donc une apostrophe seule !
http://www.abelcheung.org/advisory/20071210-wordpress-charse(...)
http://www.haypocalc.com/blog/index.php/2008/01/26/124-faill(...)
Côté pratique, c'est emmerdant pour l'utilisateur qui voit « l\'église » ou encore « l\\'église ».
Vivement PHP6 qui supprimer cette FIB (fausse bonne idée). D'ailleurs, la doc PHP affiche un gros avertissement : « WARNING: This feature has been DEPRECATED and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged. ».
[^] # Re: D'aiSécurité des magic quotes ?
Posté par Éric (site web personnel) . Évalué à 2.
Qui ici a un site internationalisé à l'aide d'un jeu de caractères BIG5 ? Les rares non unicode ici doivent probablement encore être en ISO 8859-1
[^] # Re: D'aiSécurité des magic quotes ?
Posté par jeffcom . Évalué à 6.
ah c'est certain, si on n'écrit qu'en anglais, pas besoin de big5... (ni de utf-8 d'ailleurs) néanmoins, il est probable que dans un petit pays appelé "Chine" ça soit utile, le big5... même chose pour celles et ceux qui veulent permettre le support du mandarin (par exemple, langue officielle de ce petit pays)... le lien pratique est là amha
[^] # Re: D'aiSécurité des magic quotes ?
Posté par Éric (site web personnel) . Évalué à 1.
'fin bon. Il doit y avoir des français qui internationalisent en mandarin. Mais ils sont suffisament rares pour que ça m'agace d'entendre rabacher ce problème à chaque fois qu'on parle d'échappement SQL comme si c'était le point le plus important, alors que ça concerne moins de 10 personnes en France et que ces 10 personnes sont probablement déjà au courant (en tout cas j'espère) ou dans un autre jeu de caractères.
[^] # Re: D'aiSécurité des magic quotes ?
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 2.
if (get_magic_quotes_gpc()) {
// fait quelque chose
}
et bien la condition sera validée, car bien configurée, mais en pratique, PHP n'aura pas appliqué les magic quotes. Conclusion, si pour être net ton application "enlève" le magic_quote si configuré[1] et bien tu vas avoir de la perte d'information. C'est donc un bug bien sévère.
Maintenant, la vraie question est de savoir comment les tests internes n'ont pas attrapé ce bug dans le cycle de développement. Un très gros travail est effectué par l'équipe de PHP pour mettre en place des tests sur le code, mais je ne sais pas comment ils simulent les différentes configurations de mod_php.
[1]: http://projects.ceondo.com/p/pluf/source/tree/master/src/Plu(...)
[^] # Re: D'aiSécurité des magic quotes ?
Posté par Mildred (site web personnel) . Évalué à 1.
Du coup, dans chacun de mes scripts (enfin, je ne fais plus beaucoup de php) je détecte la présente des magic quotes, et dans ce cas, j'enlève les quotes des variables $_GET $_POST et $_COOKIE récursivement. C'est chiant à faire.
Apprendre que ce sera supprimé pour PHP6, quel bonheur !
Surtout que je ne comprend pas à quoi ça sert niveau SQL, parce qu'en SQL, pour mettre une quote dans une chaîne, il suffit de faire 'l''église' (on double la quote), le \' n'est pas standard.
Enfin, le mieux, c'est d'utiliser les fonction d'encodage propre au SGBD, comme ça on est sûr.
[^] # Re: D'aiSécurité des magic quotes ?
Posté par Maxime (site web personnel) . Évalué à 2.
Si quelqu'un peut confirmer ou infirmer ?
# Je le savais...
Posté par Ellendhel (site web personnel) . Évalué à 4.
Merci pour l'annonce en tout cas, je ne l'ai pas (encore) vu passer ailleurs.
# Ca va jaser dans les chaumières
Posté par libre Cuauhtémoc . Évalué à -10.
http://minilien.com/?K2wKyMLWJP
[^] # Re: Ca va jaser dans les chaumières
Posté par gUI (Mastodon) . Évalué à 10.
Ne faites pas comme moi, ne cliquez pas sur son minilien, ça renvoie au jeu indiqué en signature, avec parainage (je supppose).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Ca va jaser dans les chaumières
Posté par libre Cuauhtémoc . Évalué à -10.
cf
# Gasp ...
Posté par David Carlier . Évalué à 3.
[^] # Re: Gasp ...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
[^] # Re: Gasp ...
Posté par David Carlier . Évalué à 1.
==>
[^] # Re: Gasp ...
Posté par Yth (Mastodon) . Évalué à 5.
Yth, groovy...
[^] # Re: Gasp ...
Posté par David Carlier . Évalué à 1.
[^] # Re: Gasp ...
Posté par Mildred (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.