Discussion :

[Séb.]

Avec les requêtes préparées, une requête statique fait le job. Inutile de quoter ou faire quoique ce soit de spécial pour éviter les attaques par injections SQL.

Les requêtes préparées génèrent du trafic inutile pour du one-shot.

[clavier12AZQSWX]

Selon vous, pourquoi les développeurs et les organisations utilisent toujours des versions de PHP en fin de vie ?

experience de vie :
moi : chef chef, notre appli qu'on a vendu aux clients est obsolète, on doit prévoir du temps et un budget pour la mettre à jour
le chef : mais elle marche bien là, pourquoi on devrait payer plus (temps, formation, argent,test..) si ya pas de bug. le client va pas vouloir
moi : ok chef
moi (dans ma tête) : penser à dire au chef pour les prochains contrats qu'il faut ajouter une clause forcée pour payer les maj-évolutions des appli obsolète

Pensez-vous que le langage PHP évolue trop rapidement pour permettre aux équipes de suivre le rythme ? Pourquoi ?

clairement oui

[edrobal]

Une appli devient obsolète parce que les shadoks qui développe le php ont décidé que c'est la compatibilité descendante qui est obsolète. Pourquoi ? Là est la question. Pure bêtise ou paresse intellectuelle ?

[binarygirl]

...
moi (dans ma tête) : penser à dire au chef pour les prochains contrats qu'il faut ajouter une clause forcée pour payer les maj-évolutions des appli obsolète

Je suis d'accord avec ce que vous dites, c'est pour ça que lorsqu'on fait un devis pour un projet il faut prévoir un budget optionnel pour la maintenance, en insistant sur le fait que faire l'impasse là-dessus risque de faire émerger des failles de sécurité. Au client de prendre ses responsabilités.
Demandez à Equifax combien ça peut coûter une application exposée sur Internet non patchée alors que les correctifs étaient dispo...

Par contre, ce qui est moins acceptable, c'est de fourguer une solution qui est déjà end of life à la conception et à la livraison au client... Ça pourrait même engager votre responsabilité professionnelle si vous fourguez du code vulnérable, qu'il soit le vôtre ou third-party.

[clavier12AZQSWX]

Je suis d'accord avec ce que vous dites, c'est pour ça que lorsqu'on fait un devis pour un projet il faut prévoir un budget optionnel pour la maintenance, en insistant sur le fait que faire l'impasse là-dessus risque de faire émerger des failles de sécurité. Au client de prendre ses responsabilités.
Demandez à Equifax combien ça peut coûter une application exposée sur Internet non patchée alors que les correctifs étaient dispo...

Sinon, on se retrouve à devoir payer 5€ par mois pour utiliser une techno ancienne (cf : ionos et ses anciennes versions php...) Par contre je suis d'accord pour cela (devoir payer un supplément pour une ancienne techno) car ça engendre des frais de maintenance plus important côté hébergement (création de coquille/sandbox/vm) pour mieux sécuriser les techno à faille, et les surveiller.

Par contre, ce qui est moins acceptable, c'est de fourguer une solution qui est déjà end of life à la conception et à la livraison au client... Ça pourrait même engager votre responsabilité professionnelle si vous fourguez du code vulnérable, qu'il soit le vôtre ou third-party.

rien n'empêche d'ajouter une case à cocher/close à signer : je suis conscient que je demande une technologie qui contient des failles de sécurité indépendante de mon hébergeur/éditeur. non ?
en même temps, quand on achète une bouteille d'alcool, la caissière nous demander pas de signer une feuille pour se déresponsabiliser de l'impact/risque ....