Les requêtes préparées génèrent du trafic inutile pour du one-shot.Citation:
Envoyé par floyer
Version imprimable
Les requêtes préparées génèrent du trafic inutile pour du one-shot.Citation:
Envoyé par floyer
experience de vie :Citation:
Selon vous, pourquoi les développeurs et les organisations utilisent toujours des versions de PHP en fin 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
clairement ouiCitation:
Pensez-vous que le langage PHP évolue trop rapidement pour permettre aux équipes de suivre le rythme ? Pourquoi ?
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 ?
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.Citation:
Envoyé par clavier12AZQSWX
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.
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.Citation:
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...
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 ?Citation:
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.
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 ....