Discussion :

[HighSek]

Bonjour à tous,
Afin de faire un premier audit des connexions, j'ai écrit un trigger simple qui récupère des informations à propos d'un user qui vient de se connecter.

J'arrive à récupérer :
- le nom de l'utilisateur, à travers la variable user,
- la date de connexion, à travers la variable sysdate,
- l'adresse IP, à travers

Code :

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

SYS_CONTEXT('USERENV','IP_ADDRESS')

.

Ce que je n'arrive pas à récupérer :
- Le programme/module avec lequel l'utilisateur se connecte.
Alors que normalement, cette valeur devrait provenir de la requête :

Code :

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

1
2
3
4
 
    SELECT module into prog
    from v$session
    where audsid = USERENV('sessionid');

Justement, cette requête retourne toujours null. J'ai essayé de voir ce qui se fait à propos de ce sujet, c'est la même requête qui revient toujours dans les forums. Donc je me suis dit que c'est peut être à cause d'une variable du pfile qui est mal positionnée...

Je vous remercie d'avance pour votre aide,

Bien cordialement,

PS : ci-joint, le code du trigger que j'ai écrit.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
CREATE OR REPLACE TRIGGER AUDIT_USER_ACCESS
AFTER LOGON ON DATABASE
DECLARE
    adresse_ip varchar2(1000);
    prog sys.v_$session.program%TYPE;
BEGIN
    adresse_ip := SYS_CONTEXT('USERENV','IP_ADDRESS');
 
    SELECT module into prog
    from v$session
    where audsid = USERENV('sessionid');
 
    if (prog is null) then
        prog := 'NULL';
    end if;
 
    if (adresse_ip not in ('A', 'B')
        and upper(prog) not in ('RWRUN60.EXE', 'IFRUN60.EXE')) then
        insert into audit_user_access values (user,
        TO_CHAR(SYSDATE,'DD/MM/YYYY-HH24:MI:SS'),
        adresse_ip, prog);
        commit;
    end if;
 
    EXCEPTION
    WHEN OTHERS THEN NULL;
END;
/

[mnitu]

Ca va être dur de récupérer le nom du module dans un trigger after logon.
Une application cliente se connecte à la base et ensuite elle peut positionner la valeur du module visible dans v$session via un appel au package PL/SQL (ou via OCI) dbms_application_info.set_module.

[HighSek]

Ok. Supposons que ce client n'est pas censé avoir le droit d'executer ce package, je pourrai quand même récupérer quelque chose de v$session (program ou module). Comment faire alors, autrement, pour récupérer le client avec lequel on vient de se connecter ?

[Vincent Rogier]

@mnitu

Juste pour information, ce n'est possible en OCI que depuis 10gR1

Le PL a toujours une longueur d'avance...

[mnitu]

Ok. Supposons que ce client n'est pas censé avoir le droit d'executer ce package, je pourrai quand même récupérer quelque chose de v$session (program ou module)...

Non, vous ne pouvez pas. V$SQL

MODULE VARCHAR2(64) Contains the name of the module that was executing at the time that the SQL statement was first parsed, which is set by calling DBMS_APPLICATION_INFO.SET_MODULE

Regardez dans la doc (j'ai mis le lien vers 10R2 parce que la 9 est dans les choux) à quoi vous avez accès dans un trigger after logon



@Vincent.
Oui, mais après assez que j'ai compris c'est plus performant.

[HighSek]

Merci pour vos réponses. Je suis convaincu sur ce qu'on ne peut pas avoir comme données lorsqu'on écrit un trigger after logon.

Ok, une fois connecté, lorsque je lance une requête sur v$session, j'ai bien mon module (Sql*Plus, Forms, ...).

Comment Oracle s'arrange t-il pour récupérer cette information ?

D'après ce que j'ai compris le package dbms_application_info est grandement responsable de ça, à travers les fonctions set_module et read_module.

En fait, dans le corps du trigger, j'ai mis à jour le champ module de v$session par un

Code :

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

dbms_application_info.set_module('dummy', 'action')

.

Un select de module de v$session juste après la connexion me donne dummy.

Donc maintenant comment faire pour "setter" cette variable avec le bon programme, on supposant toujours que le client n'exécute pas ce package lors de la connexion.

Si on ne peut pas faire ça :comment alors faire un audit simple et assez complet (utilisateur, date, module/programme) sur les connexions dans Oracle 9i ?

Merci,