FAQ
This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.

--=_B3EFFD9F.640530F0

Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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

--=_B3EFFD9F.640530F0

Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

I've been tasked to ensure only certain app programs access the=20
database.
&nbsp;
I'm thinking on-logon trigger, check the program field from=20
v$session.&nbsp; unfortunately v$session is for all sessions, i can't seem =
to=20
find the view that tells me only MY info during login.&nbsp; I only want =
the=20
sid, serial#, username and program for my just now connection to the=20
database.
&nbsp;
Does this exist or am I going about this the wrong way?
&nbsp;
We're thinking of checking those fields to make sure sql*plus, toad, =
etc=20
can't connect as a particular user(even though the password is known out =
in the=20
community).
&nbsp;
any ideas would be greatly appreciated.
&nbsp;
joe
&nbsp;

Search Discussions

  • Mercadante, Thomas F at Sep 10, 2002 at 3:22 pm
    This message is in MIME format. Since your mail reader does not understand
    this format, some or all of this message may not be legible.

    ------_=_NextPart_001_01C258DD.E060F524
    Content-Type: text/plain;

    charset="iso-8859-1"

    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;
  • Lord, David - CSG at Sep 10, 2002 at 3:35 pm
    This message is in MIME format. Since your mail reader does not understand
    this format, some or all of this message may not be legible.

    ------_=_NextPart_001_01C258DF.B2F30EE0
    Content-Type: text/plain; charset="ISO-8859-1"

    Joe


    You can use the sys_context function to get the auditing session id -


    select * from v$session where audsid = sys_context('USERENV','SESSIONID');


    David Lord

    -----Original Message-----
    From: JOE TESTA
    Sent: 10 September 2002 16:58
    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


    This message (including any attachments) is confidential and may be
    legally privileged. If you are not the intended recipient, you should
    not disclose, copy or use any part of it - please delete all copies
    immediately and notify the Hays Group Email Helpdesk at
    email.helpdesk_at_hays.plc.uk
    Any information, statements or opinions contained in this message
    (including any attachments) are given by the author. They are not
    given on behalf of Hays unless subsequently confirmed by an individual
    other than the author who is duly authorised to represent Hays.


    A member of the Hays plc group of companies.
    Hays plc is registered in England and Wales number 2150950.
    Registered Office Hays House Millmead Guildford Surrey GU2 4HJ.

    ------_=_NextPart_001_01C258DF.B2F30EE0
    Content-Type: text/html; charset="ISO-8859-1"

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

    Joe
    &nbsp;
    You can use the sys_context function to get
    the auditing session id -
    &nbsp;
    &nbsp;
    select * from v$session where audsid =
    sys_context('USERENV','SESSIONID');
    &nbsp;
    David Lord

    -----Original Message-----From: JOE TESTA
    Sent: 10 September 2002
    16:58To: Multiple recipients of list ORACLE-LSubject:
    methodology to keep only certain programs to connect to
    I've been tasked to ensure only certain app programs access the
    database.
    &nbsp;
    I'm thinking on-logon trigger, check the program field from
    v$session.&nbsp; unfortunately v$session is for all sessions, i can't seem to
    find the view that tells me only MY info during login.&nbsp; I only want the
    sid, serial#, username and program for my just now connection to the
    database.

    &nbsp;
    Does this exist or am I going about this the wrong way?
    &nbsp;
    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).

    &nbsp;
    any ideas would be greatly appreciated.
    &nbsp;
    joe
    &nbsp;

    **********************************************************************

    This message (including any attachments) is confidential and may be
    legally privileged. If you are not the intended recipient, you should
    not disclose, copy or use any part of it - please delete all copies
    immediately and notify the Hays Group Email Helpdesk at
    email.helpdesk_at_hays.plc.uk
    Any information, statements or opinions contained in this message
    (including any attachments) are given by the author. They are not
    given on behalf of Hays unless subsequently confirmed by an individual
    other than the author who is duly authorised to represent Hays.

    A member of the Hays plc group of companies.
    Hays plc is registered in England and Wales number 2150950.
    Registered Office Hays House Millmead Guildford Surrey GU2 4HJ.

    **********************************************************************
  • Fink, Dan at Sep 10, 2002 at 3:50 pm
    This message is in MIME format. Since your mail reader does not understand
    this format, some or all of this message may not be legible.

    ------_=_NextPart_001_01C258E1.CA348280
    Content-Type: text/plain;

    charset="iso-8859-1"

    Can you use the USERENV or SYS_CONTEXT function?

    -----Original Message-----
    From: JOE TESTA
    Sent: Tuesday, September 10, 2002 9: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


    ------_=_NextPart_001_01C258E1.CA348280
    Content-Type: text/html;

    charset="iso-8859-1"

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

    Can you use the USERENV or SYS_CONTEXT
    function?

    -----Original Message-----From: JOE TESTA
    Sent: Tuesday, September 10, 2002
    9:58 AMTo: Multiple recipients of list ORACLE-LSubject:
    methodology to keep only certain programs to connect to
    I've been tasked to ensure only certain app programs access the
    database.
    &nbsp;
    I'm thinking on-logon trigger, check the program field from
    v$session.&nbsp; unfortunately v$session is for all sessions, i can't seem to
    find the view that tells me only MY info during login.&nbsp; I only want the
    sid, serial#, username and program for my just now connection to the
    database.
    &nbsp;
    Does this exist or am I going about this the wrong way?
    &nbsp;
    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).
    &nbsp;
    any ideas would be greatly appreciated.
    &nbsp;
    joe
    &nbsp;
  • Kirsh, Gary at Sep 10, 2002 at 3:53 pm
    This message is in MIME format. Since your mail reader does not understand
    this format, some or all of this message may not be legible.

    ------_=_NextPart_001_01C258E2.15640CD2
    Content-Type: text/plain;

    charset="iso-8859-1"

    Select sid
    from v$msystat
    where rownum = 1



    Gary Kirsh
    Next Extent Consulting

    -----Original Message-----
    From: JOE TESTA
    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


    ------_=_NextPart_001_01C258E2.15640CD2
    Content-Type: text/html;

    charset="iso-8859-1"

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

    Select sid
    from v$msystat
    where rownum = 1
    &nbsp;
    &nbsp;
    Gary Kirsh

    Next Extent Consulting

    -----Original Message-----From: JOE TESTA
    Sent: Tuesday, September 10, 2002
    11:58 AMTo: Multiple recipients of list ORACLE-LSubject:
    methodology to keep only certain programs to connect to
    I've been tasked to ensure only certain app programs access the
    database.
    &nbsp;
    I'm thinking on-logon trigger, check the program field from
    v$session.&nbsp; unfortunately v$session is for all sessions, i can't seem to
    find the view that tells me only MY info during login.&nbsp; I only want the
    sid, serial#, username and program for my just now connection to the
    database.
    &nbsp;
    Does this exist or am I going about this the wrong way?
    &nbsp;
    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).
    &nbsp;
    any ideas would be greatly appreciated.
    &nbsp;
    joe
    &nbsp;
  • Shaw John-P55297 at Sep 10, 2002 at 3:54 pm
    This message is in MIME format. Since your mail reader does not understand
    this format, some or all of this message may not be legible.

    ------_=_NextPart_001_01C258E2.5D9C4210
    Content-Type: text/plain;

    charset="iso-8859-1"

    use v_$mystat - it has the sid - then do your join with v$session

    -----Original Message-----
    From: JOE TESTA
    Sent: Tuesday, September 10, 2002 10: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


    ------_=_NextPart_001_01C258E2.5D9C4210
    Content-Type: text/html;

    charset="iso-8859-1"

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

    use v_$mystat - it has the sid - then do
    your join with v$session

    -----Original Message-----From: JOE TESTA
    Sent: Tuesday, September 10, 2002
    10:58 AMTo: Multiple recipients of list ORACLE-LSubject:
    methodology to keep only certain programs to connect to
    I've been tasked to ensure only certain app programs access the
    database.
    &nbsp;
    I'm thinking on-logon trigger, check the program field from
    v$session.&nbsp; unfortunately v$session is for all sessions, i can't seem to
    find the view that tells me only MY info during login.&nbsp; I only want the
    sid, serial#, username and program for my just now connection to the
    database.
    &nbsp;
    Does this exist or am I going about this the wrong way?
    &nbsp;
    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).
    &nbsp;
    any ideas would be greatly appreciated.
    &nbsp;
    joe
    &nbsp;
  • Nastase, Mr. C. (Catalin) at Sep 10, 2002 at 3:57 pm
    This message is in MIME format. Since your mail reader does not understand
    this format, some or all of this message may not be legible.

    ------_=_NextPart_001_01C258E2.D43CC200
    Content-Type: text/plain;

    charset="ISO-8859-1"
    Content-Transfer-Encoding: quoted-printable

    Joe,
    =20
    you may try:=20
    select sid, serial#, username, program from v$session where audsid =3D
    userenv( 'sessionid')
    =20
    Regards,
    Catalin Nastase
    =20

    -----Message d'origine-----
    De: JOE TESTA
    Date: mardi 10 septembre 2002 17:58
    =C0: Multiple recipients of list ORACLE-L
    Objet: methodology to keep only certain programs to connect to

    I've been tasked to ensure only certain app programs access the =
    database.
    =20
    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.
    =20
    Does this exist or am I going about this the wrong way?
    =20
    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).
    =20
    any ideas would be greatly appreciated.
    =20
    joe
    =20

    ------_=_NextPart_001_01C258E2.D43CC200
    Content-Type: text/html;

    charset="ISO-8859-1"
    Content-Transfer-Encoding: quoted-printable

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

    Joe,
    &nbsp;
    you may try:=20

    select sid, =
    serial#,=20
    username, program from v$session where audsid =3D userenv(=20
    'sessionid')
    &nbsp;
    Regards,
    Catalin=20
    Nastase
    &nbsp;

    -----Message d'origine-----De: JOE TESTA=20
    Date: mardi 10 septembre =
    2002=20
    17:58=C0: Multiple recipients of list =
    ORACLE-LObjet:=20
    methodology to keep only certain programs to connect to
    I've been tasked to ensure only certain app programs access the=20
    database.
    &nbsp;
    I'm thinking on-logon trigger, check the program field from=20
    v$session.&nbsp; unfortunately v$session is for all sessions, i can't =
    seem to=20
    find the view that tells me only MY info during login.&nbsp; I only =
    want the=20
    sid, serial#, username and program for my just now connection to the=20
    database.

    &nbsp;
    Does this exist or am I going about this the wrong way?
    &nbsp;
    We're thinking of checking those fields to make sure sql*plus, =

    toad, etc=20
    can't connect as a particular user(even though the password is known =
    out in=20
    the community).

    &nbsp;
    any ideas would be greatly appreciated.
    &nbsp;
    joe
  • Stephane Faroult at Sep 10, 2002 at 4:07 pm
    Joe,

    Create a view over V$SESSION with the condition

    where audsid = SYS_CONTEXT('USERENV', 'SESSIONID')

    call it USER_SESSION and grant SELECT TO PUBLIC on it.

    --
    Regards,

    Stephane Faroult
    Oriole Software
  • Stephane Faroult at Sep 10, 2002 at 4:10 pm
    More thoughts :

    SQL*Plus fills MODULE in, don't know about TOAD (I think it does),
    but typically a number of PC clients may appear as the name of a DLL. I
    think that you shoud rather allow in than exclude out, and (ab)use
    DBMS_APPLICATION_INFO in the programs which are allowed.

    --
    Regards,

    Stephane Faroult
    Oriole Software
  • Markham, Richard at Sep 10, 2002 at 4:14 pm
    This message is in MIME format. Since your mail reader does not understand
    this format, some or all of this message may not be legible.

    ------_=_NextPart_001_01C258E5.2AC4C990
    Content-Type: text/plain;

    charset="iso-8859-1"

    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
    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;
  • Thomas Day at Sep 10, 2002 at 4:19 pm
    Yes. This works great. You posted your logon trigger before and I've =
    used
    it with considerable success (and modification). We (will) use the log=
    on
    trigger to ensure that a particular Oracle userid is logged on only fro=
    m
    one machine (no "sharing" of userids). We also allow certain exemption=
    s,
    either by userid or machine. I'll post our trigger but it's based on M=
    r.
    Mercandante's ideas.

    --create_LOGON_MULTIPLE_CHECK.sql
    CREATE OR REPLACE TRIGGER LOGON_MULTIPLE_CHECK

    AFTER logon ON DATABASE
    DECLARE

    client_info_str V$SESSION.CLIENT_INFO%TYPE;
    var_username V$SESSION.USERNAME%TYPE :=3D null;
    kill_Login EXCEPTION;
    PRAGMA EXCEPTION_INIT( kill_Login, -20997 );
    begin
    -- Set information string to uniquely identify this session

    client_info_str :=3D 'Logon_Trigger_' || LTRIM(dbms_random.value,'=
    .');
    -- Push information string into v$session

    DBMS_APPLICATION_INFO.SET_CLIENT_INFO(client_info_str);
    -- query v$session and see if this user is logged on twice on machines =
    that
    are not exempt

    begin
    SELECT unique(b.username)
    INTO var_username
    -- look for more than one logon
    from v$session a,v$session b where a.username=3Db.username=

    is the user exempt?
    trim off the null character that occasionally gets added to the name=

    AND rtrim(A.USERNAME,CHR(0)) NOT IN (SELECT LME_exemptee FROM=

    LOGON_MULTIPLE_EXEMPTIONS WHERE LME_exemption_type =3D '=
    U')
    -- look for two different machines

    and a.machine !=3D b.machine
    -- are any of the machines exempt?
    -- trim off the null character that occasionally gets added to the mach=
    ine
    name

    AND rtrim(A.MACHINE,CHR(0)) NOT IN (SELECT LME_exemptee FROM
    LOGON_MULTIPLE_EXEMPTIONS WHERE LME_exemption_type =3D '=
    M')
    AND rtrim(B.MACHINE,CHR(0)) NOT IN (SELECT LME_exemptee FROM
    LOGON_MULTIPLE_EXEMPTIONS WHERE LME_exemption_type =3D '=

    M')
    -- make sure that we are looking at this logon session

    and a.client_info=3Dclient_info_str;
    EXCEPTION WHEN OTHERS THEN
    NULL;
    end;

    -- if the user has a logon from more than 1 non-exempt machine then ki=
    ll
    this logon!

    IF var_username is not null
    THEN
    RAISE kill_Login;
    END IF;
    EXCEPTION
    WHEN kill_Login THEN
    RAISE_APPLICATION_ERROR(-20997,'This account is logged on vi=

    a
    another machine!');

    WHEN OTHERS THEN
    null;

    END;

    /

    Hope this helps and thanks Tom.

    =
    =20
    "Mercadante, =
    =20
    Thomas F" To: Multiple recipients of=
    list ORACLE-L =20
    =
    =20
    Sent by: root =
    =20
    =
    =20
    =
    =20
    09/10/2002 =
    =20
    12:23 PM =
    =20
    Please =
    =20
    respond to =
    =20
    ORACLE-L =
    =20
    =
    =20
    =
    =20

    Joe,

    I use the following with decent success on a logon database trigger:

    --=A0 Set a unique string for the session and update the session info.=

    client_info_str :=3D '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
  • Kevin Lange at Sep 10, 2002 at 4:53 pm
    This message is in MIME format. Since your mail reader does not understand
    this format, some or all of this message may not be legible.

    ------_=_NextPart_001_01C258EA.9149CE40
    Content-Type: text/plain;

    charset="iso-8859-1"

    With a setup like this, how do you stop a user from simply renaming the
    program they are using to match what you expect to see and, therefore,
    getting past your security ??

    -----Original Message-----
    From: Shaw John-P55297
    Sent: Tuesday, September 10, 2002 11:59 AM
    To: Multiple recipients of list ORACLE-L
    Subject: RE: methodology to keep only certain programs to connect to

    use v_$mystat - it has the sid - then do your join with v$session

    -----Original Message-----
    From: JOE TESTA
    Sent: Tuesday, September 10, 2002 10: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


    ------_=_NextPart_001_01C258EA.9149CE40
    Content-Type: text/html;

    charset="iso-8859-1"

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

    With a setup like this, how do you stop a
    user from simply renaming the program they are using to match what you expect to
    see and, therefore, getting past your security ??

    -----Original Message-----From: Shaw John-P55297
    Sent: Tuesday, September 10, 2002
    11:59 AMTo: Multiple recipients of list ORACLE-LSubject:
    RE: methodology to keep only certain programs to connect
    to
    use v_$mystat - it has the sid - then do
    your join with v$session

    -----Original Message-----From: JOE TESTA
    Sent: Tuesday, September 10, 2002
    10:58 AMTo: Multiple recipients of list
    ORACLE-LSubject: methodology to keep only certain programs to
    connect to
    I've been tasked to ensure only certain app programs access the
    database.
    &nbsp;
    I'm thinking on-logon trigger, check the program field from
    v$session.&nbsp; unfortunately v$session is for all sessions, i can't seem
    to find the view that tells me only MY info during login.&nbsp; I only want
    the sid, serial#, username and program for my just now connection to the
    database.
    &nbsp;
    Does this exist or am I going about this the wrong way?
    &nbsp;
    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).
    &nbsp;
    any ideas would be greatly appreciated.
    &nbsp;
    joe
    &nbsp;
  • Jared.Still_at_radisys.com at Sep 10, 2002 at 4:55 pm
    Joe,

    Try this:

    select

    s.username,
    s.sid,
    s.serial#

    from v$session s
    where userenv('SESSIONID') = s.audsid;

    Jared

    "JOE TESTA"
    Sent by: root_at_fatcity.com
    09/10/2002 08:58 AM
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L
    cc:
    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 TESTA at Sep 10, 2002 at 4:58 pm
    This is a MIME message. If you are reading this text, you may want to
    consider changing to a mail reader or gateway that understands how to
    properly handle MIME multipart messages.

    --=_BEE2F0B1.6E0F3AEF

    Content-Type: text/plain; charset=US-ASCII
    Content-Transfer-Encoding: quoted-printable

    Jared(and others)=20
    thanks, a bunch you all had what i was looking for perfectly.

    joe
    09/10/02 12:55PM >>>
    Joe,

    Try this:

    select

    s.username,
    s.sid,
    s.serial#

    from v$session s
    where userenv('SESSIONID') =3D s.audsid;

    Jared

    "JOE TESTA"
    Sent by: root_at_fatcity.com
    09/10/2002 08:58 AM
    Please respond to ORACLE-L

    To: Multiple recipients of list ORACLE-L =

    cc:=20
    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.=20
    unfortunately v$session is for all sessions, i can't seem to find the =
    view=20
    that tells me only MY info during login. I only want the sid, serial#,=20
    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=20
    can't connect as a particular user(even though the password is known =
    out=20
    in the community).

    any ideas would be greatly appreciated.

    joe

    --=_BEE2F0B1.6E0F3AEF

    Content-Type: text/html; charset=ISO-8859-1
    Content-Transfer-Encoding: quoted-printable
    Content-Description: HTML

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

    2px">
    Jared(and others)
    thanks, a bunch you all had what i was looking for perfectly.
    &nbsp;

    joe
    &gt;&gt;&gt; &lt;Jared.Still_at_radisys.com&gt; 09/10/02 =
    12:55PM=20
    &gt;&gt;&gt;Joe,Try this:select&nbsp;&nbsp;=20
    s.username,&nbsp;&nbsp; s.sid,&nbsp;&nbsp; s.serial#from =
    v$session=20
    swhere&nbsp; userenv('SESSIONID') =3D=20
    s.audsid;Jared"JOE TESTA"=20
    &lt;JTESTA_at_longaberger.com&gt;Sent by: root_at_fatcity.com09/10/2002 =
    08:58=20
    AMPlease respond to=20
    ORACLE-L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    To:&nbsp;&nbsp;&nbsp;&nbsp; Multiple recipients of list ORACLE-L=20
    &lt;ORACLE-L_at_fatcity.com&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
    cc:=20
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; methodology to keep =
    only=20
    certain programs to connect toI've been tasked to ensure =
    only=20
    certain app programs access the database.I'm thinking on-logon =
    trigger,=20
    check the program field from v$session. unfortunately v$session is for =
    all=20
    sessions, i can't seem to find the view that tells me only MY info =
    during=20
    login.&nbsp; I only want the sid, serial#, username and program for my =
    just=20
    now connection to the database.Does this exist or am I going about =
    this=20
    the wrong way?We're thinking of checking those fields to make =
    sure=20
    sql*plus, toad, etc can't connect as a particular user(even though =
    the=20
    password is known out in the community).any ideas would be =
  • Mercadante, Thomas F at Sep 10, 2002 at 5:32 pm
    This message is in MIME format. Since your mail reader does not understand
    this format, some or all of this message may not be legible.

    ------_=_NextPart_001_01C258F0.17F074A8
    Content-Type: text/plain;

    charset="iso-8859-1"

    Kevin,


    That has been my point in the past. It is really not feasible to establish
    connection policy this way.


    For example: anybody can change the name of the sqlplus.exe executable on
    their desktop, run it, and connect to the database. v$session.program now
    reports the new executable name - not sqlplus.


    The same goes for any tool on the desktop - including odbc connections.


    Security policy has to start at the account/password level.


    Tom Mercadante
    Oracle Certified Professional

    -----Original Message-----
    From: Kevin Lange
    Sent: Tuesday, September 10, 2002 1:54 PM
    To: Multiple recipients of list ORACLE-L
    Subject: RE: methodology to keep only certain programs to connect to

    With a setup like this, how do you stop a user from simply renaming the
    program they are using to match what you expect to see and, therefore,
    getting past your security ??

    -----Original Message-----
    From: Shaw John-P55297
    Sent: Tuesday, September 10, 2002 11:59 AM
    To: Multiple recipients of list ORACLE-L
    Subject: RE: methodology to keep only certain programs to connect to

    use v_$mystat - it has the sid - then do your join with v$session

    -----Original Message-----
    From: JOE TESTA
    Sent: Tuesday, September 10, 2002 10: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


    ------_=_NextPart_001_01C258F0.17F074A8
    Content-Type: text/html;

    charset="iso-8859-1"

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

    Kevin,
    &nbsp;
    That has been my point in the past.&nbsp; It
    is really not feasible to establish connection policy this way.
    &nbsp;
    For example:&nbsp; anybody can change the
    name of the sqlplus.exe executable on their desktop, run it, and connect to the
    database.&nbsp; v$session.program now reports the new executable name - not
    sqlplus.
    &nbsp;
    The same goes for any tool on the desktop -
    including odbc connections.
    &nbsp;
    Security policy has to start at the
    account/password level.
    &nbsp;
    Tom Mercadante Oracle
    Certified Professional

    -----Original Message-----From: Kevin Lange
    Sent: Tuesday, September 10, 2002 1:54
    PMTo: Multiple recipients of list ORACLE-LSubject: RE:
    methodology to keep only certain programs to connect to
    With a setup like this, how do you stop a
    user from simply renaming the program they are using to match what you expect
    to see and, therefore, getting past your security ??

    -----Original Message-----From: Shaw John-P55297
    Sent: Tuesday, September 10, 2002
    11:59 AMTo: Multiple recipients of list
    ORACLE-LSubject: RE: methodology to keep only certain programs to
    connect to
    use v_$mystat - it has the sid - then do
    your join with v$session


    -----Original Message-----From: JOE TESTA
    Sent: Tuesday, September 10,
    2002 10:58 AMTo: Multiple recipients of list
    ORACLE-LSubject: methodology to keep only certain programs to
    connect to
    I've been tasked to ensure only certain app programs access the
    database.
    &nbsp;
    I'm thinking on-logon trigger, check the program field from
    v$session.&nbsp; unfortunately v$session is for all sessions, i can't seem
    to find the view that tells me only MY info during login.&nbsp; I only
    want the sid, serial#, username and program for my just now connection to
    the database.
    &nbsp;
    Does this exist or am I going about this the wrong way?
    &nbsp;
    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).
    &nbsp;
    any ideas would be greatly appreciated.
    &nbsp;
    joe
  • Glenn Stauffer at Sep 10, 2002 at 5:37 pm
    I'm working with an application that uses a combination of encrypted
    seed numbers and password protected roles to limit access to the
    application tables to the specific application and version.

    In this database, any external application (sqlplus, etc) cannot provide
    access to the application tables since that requires activation of the
    password protected role. The only default role for users is a connect
    role that has only connect privs. And, you can't just grab a copy of
    the application from anywhere and use it against the database since the
    encrypted seed number compiled into the application is checked against
    the value in the database before a connection is permitted.

    Glenn Stauffer
    On Tue, 2002-09-10 at 11:58, JOE TESTA wrote:
    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.
  • Jared.Still_at_radisys.com at Sep 10, 2002 at 7:01 pm
    You can't.

    This is one of the reasons I haven't tried to use this.

    Jared

    Kevin Lange
    Sent by: root_at_fatcity.com
    09/10/2002 10:53 AM
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L
    cc:
    Subject: RE: methodology to keep only certain programs to connect to

    With a setup like this, how do you stop a user from simply renaming the
    program they are using to match what you expect to see and, therefore,
    getting past your security ??
    -----Original Message-----
    From: Shaw John-P55297
    Sent: Tuesday, September 10, 2002 11:59 AM
    To: Multiple recipients of list ORACLE-L
    Subject: RE: methodology to keep only certain programs to connect to

    use v_$mystat - it has the sid - then do your join with v$session
    -----Original Message-----
    From: JOE TESTA
    Sent: Tuesday, September 10, 2002 10: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.
  • Thomas Day at Sep 10, 2002 at 7:24 pm
    My experience is that an invalid trigger doesn't fire --- no effect.

    Also, userids with the DBA role don't fire the trigger. So you can't l=
    ock
    yourself out of the database. Just go in with a DBA role userid and dr=
    op
    the logon trigger.

    =
    =20
    "Markham, =
    =20
    Richard" To: Multiple recipients of=
    list ORACLE-L =20
    =
    =20
    Sent by: root =
    =20
    =
    =20
    =
    =20
    09/10/2002 =
    =20
    01:18 PM =
    =20
    Please =
    =20
    respond to =
    =20
    ORACLE-L =
    =20
    =
    =20
    =
    =20

    what are the drawbacks with such a trigger, what if the code went inva=
    lid
    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
    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:

    --=A0 Set a unique string for the session and update the session info.=

    client_info_str :=3D '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
  • Kevin Lange at Sep 10, 2002 at 7:37 pm
    I have always thought this was the best way to implement a security package.
    Nice to see you implemented the seed number for changing encryption.

    -----Original Message-----
    From: Glenn Stauffer
    Sent: Tuesday, September 10, 2002 1:49 PM
    To: Multiple recipients of list ORACLE-L
    Subject: Re: methodology to keep only certain programs to connect to

    I'm working with an application that uses a combination of encrypted
    seed numbers and password protected roles to limit access to the
    application tables to the specific application and version.

    In this database, any external application (sqlplus, etc) cannot provide
    access to the application tables since that requires activation of the
    password protected role. The only default role for users is a connect
    role that has only connect privs. And, you can't just grab a copy of
    the application from anywhere and use it against the database since the
    encrypted seed number compiled into the application is checked against
    the value in the database before a connection is permitted.

    Glenn Stauffer
    On Tue, 2002-09-10 at 11:58, JOE TESTA wrote:
    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
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Glenn Stauffer
    INET: stauffer_at_swarthmore.edu

    Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
    San Diego, California -- Public Internet access / Mailing Lists
    --------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Jamadagni, Rajendra at Sep 10, 2002 at 7:50 pm
    This message is in MIME format. Since your mail reader does not understand
    this format, some or all of this message may not be legible.

    ------=_NextPartTM-000-8becd5e7-c4f3-11d6-a0dc-00508bbd2e09
    Content-Type: multipart/alternative;

    boundary="----_=_NextPart_001_01C25903.4840DEA0"

    ------_=_NextPart_001_01C25903.4840DEA0
    Content-Type: text/plain;

    charset="iso-8859-1"

    Revoke all roles from all apps. You will have to change some code in
    authorized apps to enable roles after they log in to allow them to access
    the database. All stray applications won't do this, so even if they log in
    they won't be able to access anything.

    BTW SQLPLUS and TOAD use dbms_application_info to set the module column in
    v$session. This you can capture in db-logon trigger and kill them. At that
    stage, it is way too early to change the module information.

    Raj

    Rajendra Jamadagni MIS, ESPN Inc.
    Rajendra dot Jamadagni at ESPN dot com
    Any opinion expressed here is personal and doesn't reflect that of ESPN Inc.

    QOTD: Any clod can have facts, but having an opinion is an art!

    -----Original Message-----
    From: Jared.Still_at_radisys.com
    Sent: Tuesday, September 10, 2002 4:03 PM
    To: Multiple recipients of list ORACLE-L
    Subject: RE: methodology to keep only certain programs to connect to

    You can't.

    This is one of the reasons I haven't tried to use this.

    Jared

    ------_=_NextPart_001_01C25903.4840DEA0
    Content-Type: text/html;

    charset="iso-8859-1"
    Content-Transfer-Encoding: quoted-printable

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

    RE: methodology to keep only certain programs to connect =
    to

    Revoke all roles from all apps. You will have to =
    change some code in authorized apps to enable roles after they log in =
    to allow them to access the database. All stray applications won't do =
    this, so even if they log in they won't be able to access =
    anything.

    BTW SQLPLUS and TOAD use dbms_application_info to set =
    the module column in v$session. This you can capture in db-logon =
    trigger and kill them. At that stage, it is way too early to change the =
    module information.

    Raj

    SIZE=3D2>______________________________________________________

    Rajendra Jamadagni&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIS, ESPN Inc.
    Rajendra dot Jamadagni at ESPN dot com
    Any opinion expressed here is personal and doesn't =
    reflect that of ESPN Inc.
    QOTD: Any clod can have facts, but having an opinion =
    is an art!

    -----Original Message-----
    From: Jared.Still_at_radisys.com [
    HREF=3D"mailto:Jared.Still_at_radisys.com">mailto:Jared.Still_at_radisys.com]
    Sent: Tuesday, September 10, 2002 4:03 PM
    To: Multiple recipients of list ORACLE-L
    Subject: RE: methodology to keep only certain =
    programs to connect to

    You can't.

    This is one of the reasons I haven't tried to use =
    this.

    Jared

    ------_=_NextPart_001_01C25903.4840DEA0--

    ------=_NextPartTM-000-8becd5e7-c4f3-11d6-a0dc-00508bbd2e09
    Content-Type: text/plain;

    name="ESPN_Disclaimer.txt"
    Content-Transfer-Encoding: 7bit
    Content-Disposition: attachment;

    filename="ESPN_Disclaimer.txt"

    ********************************************************************This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*********************************************************************2
  • Kurth, Michael J. at Sep 11, 2002 at 12:43 pm
    This message is in MIME format. Since your mail reader does not understand
    this format, some or all of this message may not be legible.

    ------_=_NextPart_001_01C25990.C7620E10
    Content-Type: text/plain;

    charset="iso-8859-1"

    I have seen invalid triggers cause ORA-604 errors.

    -----Original Message-----
    From: Markham, Richard
    Sent: Tuesday, September 10, 2002 12:19 PM
    To: Multiple recipients of list ORACLE-L
    Subject: RE: methodology to keep only certain programs to connect to

    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
    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
  • Mark J. Bobak at Sep 11, 2002 at 1:10 pm
    Hmm...feels like I missed something here. Joe, in response to your
    original question, try:
    select from v$session where audsid=userenv('sessionid');

    That ought to return data for only your current session.

    -Mark
    On Wed, 2002-09-11 at 09:13, Yechiel Adar wrote:
    Hello Joe

    I implemented today Tom's trigger in one of our test databases and it works fine.
    I am using it to track which users / applications are connecting so we can notify them
    in case of scheduled down time or problems.

    You need to run dbmsrand.sql to add dbms_random package to the database.

    Yechiel Adar
    Mehish
    ----- Original Message -----
    From: JOE TESTA
    To: Multiple recipients of list ORACLE-L
    Sent: Tuesday, September 10, 2002 5:58 PM
    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
    --
    --
    Mark J. Bobak
    Oracle DBA
    mark_at_bobak.net
    "It is not enough to have a good mind. The main thing is to use it
  • Yechiel Adar at Sep 11, 2002 at 1:16 pm
    This is a multi-part message in MIME format.

    ------=_NextPart_000_03B0_01C259A6.2959F640
    Content-Type: text/plain;

    charset="iso-8859-1"
    Content-Transfer-Encoding: quoted-printable

    Hello Joe

    I implemented today Tom's trigger in one of our test databases and it =
    works fine.
    I am using it to track which users / applications are connecting so we =
    can notify them
    in case of scheduled down time or problems.

    You need to run dbmsrand.sql to add dbms_random package to the database.

    Yechiel Adar
    Mehish

    Original Message -----=20
    From: JOE TESTA=20
    To: Multiple recipients of list ORACLE-L=20
    Sent: Tuesday, September 10, 2002 5:58 PM
    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

    ------=_NextPart_000_03B0_01C259A6.2959F640
    Content-Type: text/html;

    charset="iso-8859-1"
    Content-Transfer-Encoding: quoted-printable

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

    http-equiv=3DContent-Type>

    style=3D"FONT: 10pt Times New Roman; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">

    Hello Joe
    &nbsp;
    I implemented today Tom's trigger in =

    one of our=20
    test databases and it works fine.
    I am using it to track which users / =
    applications=20
    are connecting so we can notify them
    in case of scheduled down time or=20
    problems.
    &nbsp;
    You need to run dbmsrand.sql to add =
    dbms_random=20
    package to the database.

    &nbsp;
    Yechiel AdarMehish

    style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
    0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
    ----- Original Message -----
    From:=20

    title=3DJTESTA_at_longaberger.com>JOE=20
    TESTA
    To: title=3DORACLE-L_at_fatcity.com>Multiple recipients of list ORACLE-L =

    Sent: Tuesday, September 10, =
    2002 5:58=20
    PM
    Subject: methodology to keep =
    only certain=20
    programs to connect to

    I've been tasked to ensure only certain app programs access the=20
    database.
    &nbsp;
    I'm thinking on-logon trigger, check the program field from=20
    v$session.&nbsp; unfortunately v$session is for all sessions, i can't =
    seem to=20
    find the view that tells me only MY info during login.&nbsp; I only =
    want the=20
    sid, serial#, username and program for my just now connection to the=20
    database.
    &nbsp;
    Does this exist or am I going about this the wrong way?
    &nbsp;
    We're thinking of checking those fields to make sure sql*plus, =
    toad, etc=20
    can't connect as a particular user(even though the password is known =
    out in=20
    the community).
    &nbsp;
    any ideas would be greatly appreciated.
    &nbsp;

Related Discussions

People

Translate

site design / logo © 2022 Grokbase