Re: Piratage Mysql
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/09/2011 14:50, Jean-Yves F. Barbier a écrit :
>> Je serais intéressé par un exemple, là comme ça je ne vois pas…
>
> Bien essayé, mais pas tant que je n'ai pas fini et publié mon projet.
OK, je m'attendais à cette réponse =)
> C'est pourtant relativement simple: ce que tu faisais dans php tu le fais
> maintenant dans la PS, avec juste qq lignes de plus pour gérer ce type
> d'indirection.
Pour moi, une PS, c'est ni plus ni moins que du SQL enrobé dans une méthode.
Si on commence à y intégrer du code métier, j'ai l'impression qu'on
s'éloigne très fortement de l'objectif des PS.
>> Là aussi, je bloque…
>
> Les données sont totalement inaccessibles de l'extérieur sauf pour le SU de la
> DB; seules les PS y ont accès, après contrôle des droits de l'appelant.
Oui, ça d'accord, mais les PS sont quand même ultra-limitées…
Elles ne supportent pas les arguments optionnels par exemple.
Comme je te l'ai mentionné, je ne vois pas comment on peut, via du PS,
arriver à faire ce genre de trucs (pseudo-code, et non sécuritaire je le
précise avant que ça n'hurle ^_^) :
function getTopics ( string[] sortOrders ) {
return "SELECT * FROM topics ORDER BY " + sortOrders.join(",");
}
Le fait d'avoir une requête SQL « dynamique » est pour moi en totale
contradiction avec le fonctionnement même des SP. Ou en tout cas, je ne
vois pas d'autres solutions que de faire :
function getTopics ( string[] sortOrders ) {
if sortOrders.is("date", "author")
return callSPGetTopicsOrderByDateAndAuthor()
else if sortOrders.is("date")
return callSPGetTopicsOrderByDate()
else if sortOrders.is("author")
return callSPGetTopicsOrderByAuthor()
else
return callSPGetTopics()
}
On voit bien l'explosion exponentielle du nombre de SP…
La seule solution que je puisse entrevoir serait de faire :
function getTopics ( string[] sortOrders ) {
return callSPGetTopicsGeneric(sortOrders)
}
ce qui reviendrait à faire descendre les contrôles de sécurité à la SP
au lieu du PHP, et en plus je n'ose trop imaginer la tronche finale de
la SP qui doit traiter TOUS les cas de requétage de l'application
(ordres de tri, colonnes remontées, jointures possibles (bonjour la
gestion de la sécurité avec les alias qui en découlent…), critères de
sélections…).
> Non, le travail est égal, à moins bien sûr que tu n'utilise des trucs de
> débutants comme SELECT * FROM matable au lieu de SELECT col1,col2,col6 FROM
> matable.
Certes, le « SELECT * » n'est pas recommandé. Mais il a l'avantage de
permettre d'être justement indépendant des SDD derrière : si je modifie
ma table source, je n'ai pas à modifier ma requète !
Le fait de limiter la clause SELECT :
— bride l'application pour toute évolution future
— demande X requètes/SP si j'ai la même « requête »-métier mais avec
dans chaque cas un besoin de colonnes de sortie différent
>> Par exemple avec l'exemple des topics précédents, le fait de rajouter
>> une date de publication à un post par exemple, nécessite a minima
>> d'ajouter encore X stored-procs pour pouvoir gérer les filtres et les
>> tris sur cette colonne, de refondre Y stored-procs pour ajouter cette
>> date en données de sortie, etc.
>
> Pas plus que dans du code extérieur.
Il est plus facile de modifier un fichier de mapping de l'ORM / modifier
ma classe de DAO / grepper dans mes fichiers PHP (dans l'ordre de
préférence) que de grepper dans une foultitude de SP.
Surtout que supprimer un champ dans une SP, ça va encore, « grep » le
verra. Mais difficile de grepper un champ qui n'existe pas encore parce
qu'on veut l'ajouter.
Et quid de la difficulté de s'assurer que les SP du serveur sont bien
celles attendues pour la version X, et pas celles de la version X-N ?
> Dans ce cas (comme dans les autres), il *FAUT* faire signer au client un
> cahier des charges exhaustif
Le cahier des charges était exhaustif pour chaque version.
On parle bien d'évolutions plusieurs mois après la mise en production.
Dans mon cas, il s'agissait d'un système de gestion de transactions
bancaires et l'évolution consistait à ajouter de nouveaux critères de
calcul (en gros des champs dans les tables, et là on a pleuré de ne pas
avoir mis de « SELECT * »…)
> - ET avant tout se rappeler qu'un pro a le DEVOIR
> (juridique!) de dire non à son client si ses desiderati sont farfelus.
À l'instant T0 de la signature du contrat, ils n'étaient pas farfelus.
À l'instant T0+18mois et 500 SP plus tard, ça l'est devenu un peu plus…
> J'ai souvenir d'un ami a qui le commercial a refilé un dossier; après (courte)
> analyse ce que voulait principalement le client se résumait à 30,000 hits à la
> seconde...
Cas classique, mais à la réponse à un appel d'offre et avant la
signature du contrat, il est souvent difficile de voir tous les futurs
points de blocage, d'autant plus que le client se gardera bien de te
signaler ceux qu'il a déjà anticipés, et que toi tu es pressé par les
délais (4 jours pour répondre à un appel d'offre de 1.000 pages).
> Ca m'a pris un temps fou en travail et réflexion pour trouver des solutions;
> donc comme dit plus haut, pas de comm tant que mon projet n'est pas
> terminé/publié (ce qui prendra le même temps... que le fût du canon pour
> refroidir:).
J'imagine bien =)
> Explique-moi la diff que tu vois entre entre des morceaux de php et
> différentes PS?
Physiquement parlant, il n'y en a aucune, tout n'est que fichiers au final.
« Métièrement » parlant, un monde sépare les 2, d'autant plus si on sort
du monde PHP.
Je peux par exemple m'appuyer sur la POO (héritage, polymorphisme,
généricité, abstraction…) pour limiter la duplication, centraliser
l'information, factoriser mon code…
Un exemple à la con : il y a de fortes chances pour que le nom de mes
tables se trouvent à un seul endroit dans mon code, quand chaque SP
devra dupliquer l'information. Idem si j'ai 2 requêtes « identiques mais
pas tout à fait », fortes chances d'arriver à factoriser tout ça au
niveau code quand les SP feront un gros copié/collé de derrière les fagots.
> Dans mon système, le MVC n'existe pas (en fait c'est la PS qui a ce rôle).
J'ai toujours du mal à voir comment.
Le but du MVC est d'obtenir une page quasi-HTML (ie. débarrasée de toute
présence de code métier) d'un côté et toute la récupération des données
de l'autre, de séparer la forme et le contenu en somme.
SP ou pas, ça n'a pas de rapport, ça ne reste que la partie M du MVC
(qui est ma DAO en JEE par exemple), il te manque encore toute la partie
C et V
> Par ailleurs je reste persuadé que l'archi 3-tiers est très loin d'être une
> panacée universelle; contrairement à ce que pense notamment la plupart des
> programmeurs, notamment web.
> Le 3-tiers est utile dans certains types d'applis bien particulières, pas dans
> toutes.
Ça se prête généralement pas trop mal à tout type d'application.
Le gros avantage du N-tiers est de permettre des évolutions (métier,
physique ou technique) très faciles.
Je change de moteur de base sans rien faire. Je remplace ma DAO JPA par
une couche web-service ou tes SP en 10min. Je scallabilise ma couche
service en 30 min.
> C'est comme pour les sites qui mettent 3' à charger la page de garde, ça n'est
> pas parce qu'on a un quadri-CPU en dev qu'on ne doit pas penser à ceux qui
> surfent avec un P3-500 - beaucoup, si ce n'est la plupart, devraient bien se
> rentrer cela dans la tête.
Certes, mais en même temps, quand tu tapes dans une table de 2To, pas
sûr que le temps de chargement du navigateur soit celui à prendre en
compte =)
> Evidemment, cela va à l'encontre de la mode actuelle où il faut pisser de la
> ligne de code au kilomètre et où bien souvent on ne se pose la bonne question
> que trop tard.
Là, le pissage de code au kilomètre, c'est clairement pas ma philosophie
non plus.
Je préfère 3 lignes qui fonctionnent, testées et validées, faites en 1
semaine, que 300 lignes hérétiques (que je me ferais une joie de
reverter !) en 2h !
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOdKaiAAoJEK8zQvxDY4P9+mIH/2we5Pw+VyWBUE/dBH1Rfgce
78XJOZpWkSBH7Xlzqu+IYlyIq+Z/zRQ09jdm8mscPAhLlS4NINWBoeWoWNAHWZI2
n8axYjHAFvaGCbIkwt9h5GQpJdOjsaw3azjjBPQEfZdcDiWdNhYmAE3Tu8l/9z9Z
m4SXZ5OjOrPLE5oYOZBTU9oQUPxUUI0k195DrBlDCGboQ+3kk6qZOs1A7GrPienJ
y7x4fb/+81KrVn+vUIp5/NAajkl85PmXG/U+3xDgSyL1wc4/AXCyzs6WDXYKf2NT
rAprOSbDrOedvPyDpZSNY48aPsjxGy4LAk57up7jT+5alwVmwzx/r4vbNtxaytc=
=WY10
-----END PGP SIGNATURE-----
Reply to: