Re: Piratage Mysql
On Sat, 17 Sep 2011 19:53:30 +0200, Aéris <aeris@imirhil.fr> wrote:
...
> OK, mais on sort totalement du cadre des procédures stockées lambda…
Tout dépend de la conception de lambda; dans le cas présent, il s'agit de
répartir les tâches équitablement entre codes int/ext.
> Et entre mettre du code dans la db ou du code dans l'appli, pour moi
> c'est du pareil au même, et sauf à demander 2× plus de travail et de
> personnes, je n'en vois pas l'intérêt.
Chacun chez soi...
Autrement dit pourquoi chercher à gérer la sécu des accès au niveau applicatif
alors que c'est déjà intégré dans la DB!?
> Bien que je ne maîtrise pas ce que permet de telles SP au niveau
> sécurité DB, j'imagine assez mal ne pas pouvoir faire ce type de
> contrôle au niveau applicatif. Peut-être me trompé-je…
Avec l'apparition de Pg ≥ 9.0 le contrôle est devenu bcp plus fin (colonnes),
il me parait donc logique que la DB s'occupe du contrôle d'accès.
Par rapport à Oracle, il manque encore qq autres contrôles, mais à la vitesse
(ET surtout la qualité) à laquelle les devs Pg vont, je ne doute pas que d'ici
la fin de l'année prochaine on y soit.
> Et qui dit 2 sources de code dit 2× plus de risque d'erreur !
Nan: ça revient au même, la différence c'est que le code ext n'exécute plus
qu'un simple appel à la SP.
...
> > J'ai mis presque une année à intégrer le fonctionnement, l'analyse et
> > l'application de tout ça à un résultat final parce que justement, même si
> > ça reste de la logique, elle est différent de celle de la programmation.
>
> Gros problème que j'y vois : cette manière de penser (que j'imagine bien
> loin de tout standard SQL et reposant sur des API propres au moteur
> utilisé), est totalement non portable, réutilisable ou généralisable.
> Tu changes de moteur, ton année de travail aura été totalement vain.
C'est en partie vrai, mais depuis qq temps on observe une convergence, à mon
avis non-fortuite, entre Pg & Oracle; et il n'y a pas tant que cela d'autres
compétiteurs du même niveau.
C'est pour cela que j'essaye de penser hors des sentiers battus; la
portabilité c'est Tbien dans l'abstrait, mais encore faut-il:
* qu'il y ait un intérêt quelconque à éventuellement switcher,
* qu'il existe un moteur capable de rendre les même services.
* que ladite portabilité ne se fasse pas au détriment des perfs.
> > Ca n'est pas pour rien que les devs de gros projets sont complètement
> > séparés entre programmation et DB: ce ne sont pas les même métiers (un peu
> > comme Erlang est totalement alien à celui qui ne fait que du Basic).
>
> Euh, sur de gros projets, les DBA s'occupent de la structuration des
> données (schémas, indexes, configuration et paramétrage du moteur…), pas
> du développement…
Ben ceux que je connais sont en Gal aussi des devs, justement parce que c'est
une discipline très différente de la programmation proprement dite.
> > Mais si on fait (tjrs en symbolique):
> > CASE 1:
> > RETURN SORTED BY Date
> > CASE 2:
> > RETURN SORTED BY Author
> > CASE 4:
> > RETURN SORTED BY Date AND Author
> > DEFAULT:
> > RAISE ERROR maPSamoi, "Illegal sort switch"
> > END CASE
> >
> > on n'a plus qu'une seule PS.
>
> C'est effectivement la solution que j'envisageait.
> Mais dans une application classique, je pense que N tend plus vers 200
> que vers 5…
Même si N=300 ça ne pose pas de PB insoluble (surtout que dans Pg, une fois
passé le premier appel qui déclenche la compilation, c'est le pseudo-code qui
est exécuté).
> > D'abord il faut savoir si TOUS ces cas de tris ont une réelle légitimité...
>
> Dans une application « classique », oui.
> Par exemple dans les écrans de reporting et/ou de traçabilité.
Eventuellement pour la traçabilité, mais normalement si la DB est bien concue
ça se traite par une table 1-1-self (et par voie de conséquence, par des appels
récursifs à la SP).
Pour le reporting c'est une toute autre histoire, notamment dans les grosses
entreprises, parce que toutes les enquêtes montrent que chaque nouveau chef
vient ajouter son grain de… sable dans la machine pour prouver qu'il existe,
mais qu'au final moins de 10% des traitements de données (en Gal les
indicateurs std) servent réellement à qq chose dans les processus de
décision/optimisation.
> > Ensuite les contrôles de sécurité DOIVENT setrouver là où la sécurité est
> > justement maximale, en l'occurence dans la DB.
>
> Pas convaincu…
> J'ai l'exemple d'une de mes applis de gestion biométriques où les
> données nominatives n'étaient accessibles que par les admins du système.
> Une partie du contrôle des accès aux colonnes de la db était donc à
> faire au niveau applicatif !
Développe un peu plus parce que là je ne vois pas le tableau.
> > C'est justement pour cela que j'appelle ça une erreur de débutant:
> > 1- Rien dans les différents normatifs SQL ne garantie l'ordre de retour des
> > données (col1,col2,col3 ou col2,col3,col1 ou...) et c'est ce qui
> > déconseille formellement le '*',
>
> C'est pour ça que je n'utilise pas le positionnel, mais bien les champs
> nommés.
Ca n'est point ce que j'avions lû qq posts plus haut, gent damoiseau!:
"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 !" SIC
> > 2- Rien n'empêche d'avoir lesdites colonnes en paramètres de la PS,
>
> Ce qui ouvre la voie à de l'injection SQL ? =)
Pas du tout, il existe des mécanismes simples dans Pg pour se prévaloir de
toute possibilité d'injection par les parms d'une SP.
...
> > Dans l'état actuel des choses, un ORM est une ineptie - tout au plus peut
> > il servir lors d'une phase de mise au point.
> > Pourquoi en rajouter une couche (qui ralentit fortement l'ensemble) alors
> > qu'une bonne conception évite cela??
>
> Un ORM, c'est pas juste un bidule qui te connecte à la base…
> Ça t'apporte pas mal d'autres choses, comme les pools de connexion, les
> caches multi-niveaux, l'indépendance du moteur…
Si j'ai besoin de pools et/ou de cache(s), je vais les chercher
individuellement là où ils sont 100% fonctionnels et très performants, pas
dans une soupe où l'on trouve tout et n'importe quoi - souvent bricolés à la
va-vite sur demande pressante des utilisateurs.
...
> > Là, je ne veux pas être méchant mais si tu distribues une MàJ du code php
> > sans celle de la DB, faut changer de métier tout de suite: c'est un tout.
>
> Si le monde était aussi rose, ça se saurait depuis longtemps =)
> Et je peux très facilement vérifier que mon client a exactement les
> mêmes fichiers que moi en production (MD5), il en est autrement pour les
> SP potentielles sur le moteur…
D'où l'intérêt d'upgrader par package complet - sinon il suffit d'ajouter une
SP qui renvoie la version (mais ça reste une Tmauvaise solution).
...
> Un client a souvent du mal à définir son futur, surtout à 18 ou 30 mois.
J'entends bien, mais dans ce cas il faut être aussi clair dans l'autre sens:
soit il aura un soft très spécialisé et totalement adapté à son cas présent
(mais qui demandera plus de travail lors d'une évolution), soit tu lui fais
un truc extrêmement malléable avec ORM, N-tiers et tout le toutim, au
détriment complet des perfs (mais qui se modifiera très facilement).
A ma connaissance dans ce domaine, il est totalement impossible d'avoir le
beurre, l'argent du beurre et le cul de la fermière (cochonne qui a des gros…,
ha non, merde, c'est l'infirmière:)
> J'ai même dans mon entreprise des demandes d'évolution sur du soft de 30
> ans d'âge !
Je pense que ça mérite une analyse poussée au cas par cas; j'ai pu jeter de
temps en temps un œil a certains vieux softs qui étaient terriblement bien
faits, alors que d'autres étaient une vraie cata.
> > Là il ne peut y avoir que 2 poss: soit l'analyse a été mal faite, soit le
> > client n'a pas été clair (voire un peu des 2).
>
> Non, juste que tout faire en SP ne nous semblait pas impossible
> techniquement, et reste d'ailleurs même encore aujourd'hui complètement
> faisable.
> Le soucis est venu au cours du développement, quand on a commencé à voir
> le nombre de SP, avec X variantes de la même requête, mais avec plus ou
> moins de données sortantes, de critères de sélection ou de tri…
Apparemment mauvaise analyse dûe à une connaissance pas assez approfondie de
la DB utilisée.
> Les développeurs s'arrachaient la tête pour savoir si une fonctionnalité
> avait déjà été SPifié ou si le travail restait à faire, pour trouver
> telle SP qui devait être corrigée, ainsi que toutes ses variations
> potentielles.
Dans ce cas, fais les passer en AGILE ou XP - je ne sais plus lequel procède
par releases rapides, mais c'est un système qui a bcp d'avantages: release
when ready AND tested, puis ajouts de fonctionnalités par releases, jusqu'à
release 1.0
> > Mais dans le cas présent, je soupçonne fortement (et à priori) un défaut de
> > conception de la DB.
>
> C'était le cas en partie, mais la base avait été héritée d'un ancien
> système et on ne pouvait pas trop y toucher.
Ha haaaa, la vieille base qu'on ne peut pas toucher - un must du classique!
C'est aussi là que la préparation pêche: soit le client conserve sa base et il
encaisse *également* les inconvénients qui vont avec, soit il y a migration
et donc création d'une Nlle base.
Parce que si tu réponds oui à une telle demande, la première merde te reviendra
dans le museau comme un boomerang (les clients ont l'amnésie absolue quand il
s'agit de responsabilité).
Là encore, c'est une question d'analyse préalable - prendre un marché, c'est
bien, mais pas s'il doit se transformer en sables mouvants dès le dev.
> Et pour achever le coup des SP, la plupart des requêtes étaient
> dépendantes d'un fichier de conf (XML) qui définissaient les règles
> métiers (répartition fonction du client, taxes variables, frais,
> ristournes commerciales…).
Là encore c'est un défaut d'analyse: comment accepter des données externes
alors qu'elles auraient dû se trouver dans la DB?
Pour te donner une idée, même les tailles & positionnements des fenêtres de mon
projet sont stockés dans la DB.
Une fois que c'est fait, on définit une ligne de process par taxe/ristourne/etc
puis les SP qui vont bien, puis la SP qui chapeaute le tout (SI il y en a
vraiment besoin, par qu'il est facile d'automatiser ce type de traitement en
chaînant les SP d'une façon transparente).
> Le nombre de paramètres à passer aux SPs étaient effroyables (jusqu'à
> 300 paramètres pour la plus grosse de mémoire).
Ca me parait, là encore, relever d'une erreur de conception liée au §
ci-dessus.
> > Les clauses réservatives sont là pour ça, d'ailleurs un contrat sur appel
> > d'offre ne devrait *jamais* être signé sans l'approbation d'un cabinet
> > d'avocat spécialisé.
>
> Les clauses sont là, mais rarement appliquées.
C'est une erreur classique et désuette; par exemple, les tribunaux du fisc ont
établi que si tu fais allusion à une clause de délai de paiement dépassé sous
astreinte d'intérêts de retards ET qu'il y a retard ET que tu ne fais pas
jouer la clause, tu es redressable sur le CA non-généré (merveille de ce pays
de cons, dirigé par des incapables tout-puissants pour qui les entreprises
sont l'ennemi à abattre).
...
> > Et si le nom de la table n'était qu'un parm d'appel de la PS?
> > Voila une idée qu'elle est bonne! (et qu'elle permet de réutiliser la PS
> > avec d'autres tables).
>
> Et de redescendre l'injection SQL un poil plus bas…
Non, comme dit plus haut, il est facile d'éviter toute injection dans une SP
postgresql.
...
> > Pour la partie C, elle est aussi incluse dans la PS.
>
> Gné ?
> Ça devient limite de l'hérésie là…
> Le jour où je rajoute des écrans, je dois toucher à ma BdD ? Oo
Si les écrans demandent des données non primitivement renvoyées, oui - mais
c'est la même chose où que se trouve le code: il faut bien modifier qq chose
pour changer le résultat.
> > Chaque outil a ses propres spécificités; par exemple tu peux faire tout ce
> > que tu veux en N-tiers en matière de communications, mais je te mettrais
> > toujours une pallée en utilisant Erlang et en scalant mon système en 3
> > lignes de code sur un nombre illimité de nodes en qq secondes.
>
> Certes, mais qui pourra maintenir ton code derrière ?
> Non pas que je défende qu'on doit pouvoir refiler la reprise de code au
> premier venu, mais à l'inverse, s'il faut que la recrue mette la même
> année que toi à comprendre le langage / système…
Tu mets le doigt sur l'un des PBs majeurs actuels: on demande aux gus sortant
d'une école d'être immédiatement opérationnels, ce qui est une ineptie totale.
D'abord parce qu'il y a une culture d'entreprise à acquérir, et que ça ne se
fait pas en un jour (eg: certains chefs demande un reporting hebdomadaire,
d'autres journalier, et ceux qui ont compris font confiance à priori); et
ensuite parce que même avec des tas de stages ils ne sont pas obligatoirement
tombés sur les même cas.
ET, très contradictoirement, les entreprises ne veulent pas assumer cette
accoutumance à leurs us et coutumes.
Sans compter qu'une entreprise est comme un individu: elle ne peut pas tout
faire, surtout au jour d'aujourd'hui où l'on demande à chacun d'être un
spécialiste.
Alors la façon simple(iste) de se défausser, c'est de tout faire, un peu
n'importe comment, tout en générant un turnover important dans le personnel
qui n'en peut rapidement plus, ce qui va au détriment des propres intérêts de
l'entreprise.
Là-dessus je pense qu'un coup d'œil sur les manières de faire de nos voisins
Teutons en particulier (et Alémaniques en Gal) permettrait d'y voir bcp plus
clair.
> > La bonne question c'est: est-ce qu'utiliser ceci ou cela apporte vraiment
> > de l'eau au moulin ou est-ce juste un pis aller pour aller plus vite (en
> > Gal au détriment de l'évolution).
>
> Oui, à long terme.
> On sait d'avance que les évolutions seront nombreuses (surtout dans mon
> domaine principal, l'industrie), et les équipes très fluctuantes (SSII).
> Le soft se doit d'être abordable tout en étant suffisamment bien gaulé.
Alors il faut pousser le raisonnement à son paroxysme et utiliser tous les
outils dispos, de l'orm à la base olap, en passant par (sèpulnom) les bases
qui s'auto-reconfigurent par (re)design des flux métiers.
Mais le risque du manque de connaissance est là aussi bien présent parce que
ces outils sont tellement généraux qu'ils demandent des compétences très
particulières (et souvent directement liées au métier-client) lors de leurs
configurations.
> > Un tout ch'tit exemple: tu dis "Je change de moteur de base sans rien
> > faire" sauf que chaque DB a certaines spécifités et que certaines, même
> > hors normes SQL, facilitent grandement la vie.
>
> C'est pour ça que Hibernate définit la notion de dialecte et se base sur
> les API propres à chaque moteur (non pas comme certains le pense en se
> conformant à la stricte norme SQL).
> Il utilisera par exemple les serial et séquences de PostgreSQL au lieu
> de l'auto-incrément MySQL.
Je ne fais pas de java, donc je n'ai pas d'opinion sur Hibernate que je ne
connais que de nom; mais je me rappelle qd même avoir lû pas mal de flammes
dessus, notamment chez Pg.
> > Un autre: ça ne me viendrait même pas à l'esprit ne serait-ce qu'envisager
> > d'éventuellement un jour peut-être de penser à mysql pour une appli
> > sérieuse.
>
> C'est bien pour ça que je l'ai fait bannir de notre bureau d'études.
> Comme remplaçant, PostgreSQL !
Voila une chose qu'elle est bien!
Comme d'hab, il n'existe pas une solution mais une multitude de solutions
possibles pour un même PB - et je veux bien concevoir que dans le cas que tu
décris, ORM et autres aides forment une béquille qui a ses avantages et ses
inconvénients en fonction de l'angle d'observation.
Le seul bémol que j'y mettrais (mais ça n'est pas simple à faire, surtout
quand on a la tête dans le guidon) serait d'évaluer en profondeur chaque outil
afin de restreindre le choix aux "bons", ou tout du moins aux plus adaptés.
--
The chicken that clucks the loudest is the one most likely to show up
at the steam fitters' picnic.
Reply to: