très bonne intégration avec Apache (les solutions en Perl et Python n'arrivaient pas à la cheville de mod_php)
Très mauvaise intégration, entraînant des problèmes de sécurité divers. En fait, il faudrait parler d'intégration simple à déployer et maintenir. Mais ce modèle a posé de nombreux problèmes par le passé, ayant entraîné des horreurs (openbasedir et autres mécanismes de pseudo-sécurité).
un fichier .php == une page
Alors certes, cela simplifie la vie de celui qui veut créer un compteur et quelques gadget pour un site personnel. Malheureusement, cette conception entraîne /de facto/ la création d'une surface d'attaque inimaginable.
conséquence des deux premiers, disponibilité très large chez les hébergeurs pas chers
C'est là qu'on est d'accord. PHP est à la programmation Web ce que MacDo est à la restauration. Et j'en mange trop (des deux).
APIs d'interaction avec MySQL en standard
Encore une fois, c'est vrai que c'est très pratique et permet de garantir des comportements, mais malheureusement, c'est un mauvais design. Une bonne pratique en sécurité, c'est de tout désactiver pour activer ce dont on a besoin. Mettre à disposition une API pour la dizaine de BDD qu'on n'utilisera jamais n'est pas un bon modèle de sécurité. Mais encore une fois, c'est un compromis coût/qualité.
[^] # Re: Noms de fonctions dans la bibliothèque standard
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Sortie de PHP 5.6. Évalué à 3.
Très mauvaise intégration, entraînant des problèmes de sécurité divers. En fait, il faudrait parler d'intégration simple à déployer et maintenir. Mais ce modèle a posé de nombreux problèmes par le passé, ayant entraîné des horreurs (openbasedir et autres mécanismes de pseudo-sécurité).
Alors certes, cela simplifie la vie de celui qui veut créer un compteur et quelques gadget pour un site personnel. Malheureusement, cette conception entraîne /de facto/ la création d'une surface d'attaque inimaginable.
C'est là qu'on est d'accord. PHP est à la programmation Web ce que MacDo est à la restauration. Et j'en mange trop (des deux).
Encore une fois, c'est vrai que c'est très pratique et permet de garantir des comportements, mais malheureusement, c'est un mauvais design. Une bonne pratique en sécurité, c'est de tout désactiver pour activer ce dont on a besoin. Mettre à disposition une API pour la dizaine de BDD qu'on n'utilisera jamais n'est pas un bon modèle de sécurité. Mais encore une fois, c'est un compromis coût/qualité.