RE: methodology to keep only certain programs to connect to

[Markham, Richard]

what are the drawbacks with such a trigger, what if the code went invalid and would not compile is it possible that you could lock yourself out, or would the base login functionality still work regardless or the status of this trigger? -----Original Message----- From: Mercadante, Thomas F [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 10, 2002 12:24 PM To: Multiple recipients of list ORACLE-L Subject: RE: methodology to keep only certain programs to connect to Joe,   I use the following with decent success on a logon database trigger:     --  Set a unique string for the session and update the session info. client_info_str := 'WTWLOGIN_' || LTRIM(dbms_random.value,'.'); DBMS_APPLICATION_INFO.SET_CLIENT_INFO(client_info_str);   -- look into the v$session view for the session just connected. SELECT program, username, osuser, terminal, machine INTO loc_program, loc_username, loc_osuser,loc_terminal,loc_machine FROM V$SESSION WHERE client_info=client_info_str;   From here, you can test the loc_program variable against the loc_username to see if the combination is correct. Stuff like:     IF loc_username='TESTLOGIN' then    RAISE kill_Login; END IF; EXCEPTION WHEN kill_Login THEN     RAISE_APPLICATION_ERROR(-20999,'Login''s using this account and this tool are Invalid');     Hope this helps!   Tom Mercadante Oracle Certified Professional -----Original Message----- From: JOE TESTA [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 10, 2002 11:58 AM To: Multiple recipients of list ORACLE-L Subject: methodology to keep only certain programs to connect to I've been tasked to ensure only certain app programs access the database.   I'm thinking on-logon trigger, check the program field from v$session.  unfortunately v$session is for all sessions, i can't seem to find the view that tells me only MY info during login.  I only want the sid, serial#, username and program for my just now connection to the database.   Does this exist or am I going about this the wrong way?   We're thinking of checking those fields to make sure sql*plus, toad, etc can't connect as a particular user(even though the password is known out in the community).   any ideas would be greatly appreciated.   joe