auditing

Bonjour,
Voila jai dans mes tables des champs audit qui me permettent de stocker notemment le nom de l'utilisateur de la base qui a ajouter un record dans la table consideree!
Jaimerais automatiser cette tache pour soulager les inserts manuels!

je peux donc
soit recupere le nom de l'user courant et donc aller piocher dans une vue qui est je crois USERS mais le probleme est- que nous avons tous le meme user pour nous connecter
soit je recupere le nom utilisateur cote client, le nom de la session XP encours mais cote securite c'est pas top

Qqchose a me suggerer?
MErci

Si vous avez tous le même user pour vous connectez c'est un problème donc dans ce cas la vous avez aussi tous le même UID.

Donc tu ne pourras pas savoir quel user à fait quoi en automatique ???

Si tu n'avais pas le même user pour tous, tu aurais pu utiliser la variable USER d'ORACLE. Si tu fais un :

Code:

---

select user from dual

---

Il te donne le nom du user.

Et donc utiliser cette variable dans un trigger sur ta table que tu déclencherais à l'insert ou update (à toi de votre quel est ton cas) record.

Voila ce que je peux te dire de ma propre expérience !!!!!!!

Gaultier Emmanuel

Voir aussi les triggers sur évènements qui permettent, via les attributs, de récupérer un certain nombre d'informations sur l'évènement et l'actionneur.

tu peux aussi utiliser la fonction sys_context avec le namespace 'userenv' pour récupérer des paramètres comme le user OS, la machine client ou l'adresse IP de l'appelant...

bonjour,
voila je cree ce code

Code:

---

1 2 3 4 5 6 7 8 9 10

CREATE OR REPLACE TRIGGER mon_audit BEFORE INSERT on MA_TABLE BEGIN INSERT INTO ma_table (mon_champ) SELECT sys_context('userenv','os_user') FROM DUAL COMMIT;   END; /

---

et je me retrouve avec ces erreurs

Code:

---

1 2 3

ORA-00036: maximum number of recursive SQL levels (50) exceeded ORA-06512: at "PROLAB.MON_AUDIT", line 2

---

tu n'as pas le droit de faire des commit dans un trigger...

si tu veux faire un insert dans une autre table et commiter cette opération quel que soit le résultat de l'opération qui a déclenché le trigger, tu dois passer par une procédure autonome...

dans ton cas je ferais

Code:

---

1 2 3 4 5 6 7 8 9

CREATE OR REPLACE TRIGGER mon_audit BEFORE INSERT on MA_TABLE my_data varchar2(20); -- ou le type qui convient à ta table / donnée BEGIN SELECT sys_context('userenv','os_user') into my_data FROM DUAL ; :new.mon_champ = my_data ; END; /

---

et tu laisses le commit ou le rollback être géré par la transaction déclenchante...

et je viens juste de voir que dans code original il manque un ; après le Select... from dual :wink:

merci
desole pour le commit c bete!

Voila le code qui fonctionne

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

CREATE OR REPLACE TRIGGER mon_audit BEFORE INSERT on MA_TABLE referencing new as new old as old for each row DECLARE my_data varchar2(20); BEGIN SELECT sys_context('userenv','os_user') into my_data from dual; :new.mon_champ := my_data ; END; /

---

Cote securite est ce que ca peut poser des problemes de faire ce genre de manipulations? On m'a dit que ce n'etait pas conseille!!!!!

merci

je ne vois quel problème... mais si qqun a un autre avis là-dessus ça m'interresse aussi...

j'utilise beaucoup ce genre de trigger pour renseigner des colonnes du style "CREATE_USER, CREATE_DATE, LASTUPDATE_USER, LASTUPDATE_DATE"...

c'est tout bête mais ça aide souvent a retrouver facilement "qui fait quoi" sans avoir des manip trop lourdes à mettre en place.

Moi aussi j'utilise beaucoup des triggers de ce type pour faire de la tracabilité d'actions (qui fait quoi et quand) et je ne vois pas pourquoi il y aurait des problèmes de sécurité.
Il n'y a pas de données importantes modifiéés c'est juste informatif comme traitement.


Gaultier Emmanuel

par contre il va de soit que ces infos ne doivent pas forcément être publiées au yeux des utilisateurs "lambda"... si tu as des rapports basés juste sur des "Select * ..." ça peut être des infos à ne pas publier à la légère... Mais là on tombe dans une logique de "sensibilité" des données.

mais en terme de sécurité de base de donnée, alors je ne vois pas.

oui en effet mais la c'est pour faciliter un developpement et ainsi eviter que les developpeurs soient obliger a chaque fois de renseigner ces champs a la main!