Re: Piratage Mysql
On Sat, 17 Sep 2011 01:07:33 +0200, Aéris <aeris@imirhil.fr> wrote:
...
> Le cœur même de PHP est totalement délirant en matière de bonnes pratiques :
> — API hétérogènes et mouvantes,
> — Intégration d'une foultitude de « librairies » directement dans le core
> — Paramétrage hérétique (magic_quote_gpc ><),
> — Aucun respect d'une quelconque de normes de codage,
Nous sommes bien d'accord sur ces points.
> Même le PHP Engine n'est pas thread-safe et plombe Apache (pre-fork au
> lieu de worker) ou incite à l'ultra-crade-pas-sécurisé (fast-cgi).
Ok pour le thread safe, pour ce qui est d'apache, c'est une autre histoire
(design vieillot, conso de RAM effarante, etc).
...
> > Mais au risque de me répéter, la meilleure parade reste d'inclure le code
> > "actif" dans la DB (procs stockées); mais je doute qu'à ce jour ce soit
> > facile (voire même possible à 100%) avec mysql.
>
> C'est extrème comme solution, et totalement innapplicable sur une
> application digne de ce nom, que cela soit en PHP ou non et MySQL ou non.
> Tu imagines le nombre de stored-proc nécessaires ?
Moins que tu ne penses: je bosse ces temps-ci avec des procs polymorphes qui
effectuent elles-même leurs propres contrôles sur tables et colonnes (Pg, œuf
corse hein, pas merdesql), d'un côté on perd le temps de contrôle à chaque
appel, de l'autre on gagne une malléabilité énorme et l'abstraction par rapport
aux données; sans compter l'interdiction totale d'accès direct à ces
mêmes données.
La maintenance n'est pas plus lourde que pour un pgm en php, voire plus légère,
parce que si l'on reprend le cas du php (hors code de mise en page), il se
contente d'effectuer des appels à des procs stockées (r/a/u/d); la proc
prenant en charge les autorisations et le traitement réel des données.
> De toutes les
> variantes de paramètres et/ou de sorties différentes ?
Non: il est relativement aisé d'écrire une proc polymorphe qui ne retourne que
les colonnes autorisées (ou renvoie une erreur si pas d'autorisation).
> Du coût monstrueux de maintenance d'un tel système ?
Pas plus que des centaines de petits morceaux de code d'un pgm en php, voire
même moins puisque chaque proc a une fonction bien déterminée (quitte à avoir
un peu de redondance dans le code afin d'éviter le morcellement).
> Et qu'une telle application serait figée dans le marbre à jamais, toute
> évolution future étant vouée à l'échec ?
Je ne comprends pas ta vue de la chose: quelle différence vois-tu entre greper
dans des centaines de bouts de code php pour s'y retrouver et modifier ces
morceaux comme voulu, et modifier directement une ou des procs stockées dans
la DB?
À part les langages différents et surtout le fait que le contrôle total
des données soit dévolu à la DB et non-plus à du code externe, je ne vois pas
où se trouve le différentiel de maintenance.
--
Don't everyone thank me at once!
-- Han Solo
Reply to: