Discussion :

[Simon_Progi]

Bonjour, voici mon problème :
Je viens d'être engagé et je me suis rendu compte que l'une des applications que nous développons (MySQL) est une application multicompagnie. C'est-à-dire que dans chaque table de la base de données il y a un champ COMPAGNY_ID qui identifie la compagnie. Le problème c'est que plusieurs stagiaires ont travaillé sur cette application et certains ont développé du code sans se préoccuper de COMPAGNY_ID ce qui cause des problèmes lorsqu'une requête retourne des valeurs n'appartenant pas à la compagnie en cours.

Moi je veux un genre de TRIGGER POST-READ qui intercepte toutes les lectures de chaque table et qui loggue dans un fichier toute requête qui retourne un enregistrement qui n'appartient pas à la compagnie en cours.

Tout le code de suivi est dans ma tête et fonctionnera. Ce que je cherche c'est comment intercepter chaque lecture de la base de données.

Merci

[punkoff]

bonjour,

un petit tour dans la doc ... : http://dev.mysql.com/doc/refman/5.6/...e-trigger.html


Et vous comprendrez que ça n'est pas possible.

[Simon_Progi]

OK, je comprends que les triggers s'appliquent en insert, update et delete mais il doit exister une façon de faire. Que ce soit au niveau du tunnel de communication, de la base de données elle-même, etc. On doit-être capable, étant DBA, de savoir ce qui est lu dans notre base de données. N'importe quelle suggestion sera étudiée.

[Linkin]

Comme solution, il y a aussi: activer les logs du serveur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
SET GLOBAL log_output = "FILE";
SET GLOBAL general_log_file = "/path/to/your/logfile.log"
SET GLOBAL general_log = 'ON';

Et ensuite les analyser.

Mais pour moi la plus sûre est de faire la liste des tables liées à une compagnie et ensuite de faire une recherche de ces tables dans le code source. Car si une requête incorrecte n'est pas exécutée, elle ne sera jamais corrigée.

[Simon_Progi]

Oui les logs sont activés mais dans ces logs on ne voit que la requête et non pas les enregistrements lus.
Peut-on avoir des logs plus complets ?

[punkoff]

Au niveau du SGBD ce n'est pas possible.


Vous pouvez vous appuyer sur des applications tierces (proxy) afin de filtrer les échanges entre votre serveur et vos clients si ceux-ci l'utilise.

Dans la même optique rajouter une couche au framework de votre application afin d'émuler ceci.


A part ca je ne vois pas d'autre solution que de prendre le mal par la racine et de faire une retro-analyse de votre application...

[valaendra]

Oui les logs sont activés mais dans ces logs on ne voit que la reuqête et non pas les enregistrements lus.
Pqut-on avoir des logs plus complets ?

A partir de la requête, on peut déduire les données qui sont lues... non ?

[Simon_Progi]

Oui je sais mais 400 tables interrogées par 70 écrans de saisie et deux trois cents rapports et productions, on parle de 100 000 et plus de requêtes par jour à re-genérer et à analyser. C'est décourageant.

[CinePhil]

N'y a t-il pas moyen de ne reprendre que ce qui a été fait par les stagiaires ?
Ce serait déjà un bon filtre, non ?

Et puis dans le log des requêtes, vous allez pouvoir détecter les requêtes qui ne prennent pas en compte la compagnie, ce qui va aider à chercher le bout de code qui lance la requête fautive et la corriger.

Bon courage :

[Simon_Progi]

Tout revoir n'est pas possible.

L'autre problème, c'est qu'on ne peut pas analyser les résultats de toutes les requêtes, car de toute façon, le No_cie n'étant pas pris en ligne de compte dans certains cas pour le lien, il ne sera pas retourné lors de la requête et donc invisible.

Salut.