Re: How to trap the user's login program and disallow if Windows based?

I found this out soon enough...:-( Or rather the developers did...;-) Or, rather, they have now ...:-)

How about querying the sql area to see if a statement unique to TOAD has been parsed and then whack the session ?

There surely has to be a unique statement issued that could be tracked...

"Thomas Kyte" <tkyte_at_oracle.com> wrote in message news:adkqg501tes_at_drn.newsguy.com...
> In article <8d4033cd.0206041503.4c37138e_at_posting.google.com>,
> enzoweb_at_hotmail.com says...
> >
> >Oracle RDBMS V8.0.6 on Solaris 2.7
> >
> >I can remember that there is a way to trap the program name a user is
> >logging into the database with, and disallow it if it is something
> >like TOAD or ACCESS.
> >
>
> and all I would do if you did that would be:
>
> copy toad.exe program_you_allow.exe
>
> then -- I'm in again.
>
> using the program column does not work in the real world
>
>
> >Here is the problem:
> >
> >We have an application which connects into the database with the
> >password hard-coded and which everyone knows. This application userid
> >is also the schema owner. The developers also use TOAD. We can change
> >the application password but it is hard coded in plain text and
> >everyone knows how to see it. So the Developers have a habit of
> >signing on to TOAD as the application owner and therefore have total
> >access to the tables.
> >
> >I know that I can create a trigger at logon to run some SQL, but
> >
> >1. Not sure if it works on the V806 we are running.
> >2. Don't know how to code it.
> >
> >So, I want it to go -
> >
> >login - check program name - if user = schema.owner and program !=
> >program.name then kill session (and maybe issue a nasty message).
> >
> >Does anyone have an example of this I can use?
> >
> >Thanks.
>
> --
> Thomas Kyte (tkyte@oracle.com) http://asktom.oracle.com/
> Expert one on one Oracle, programming techniques and solutions for Oracle.
> http://www.amazon.com/exec/obidos/ASIN/1861004826/
> Opinions are mine and do not necessarily reflect those of Oracle Corp
>
Received on Wed Jun 05 2002 - 12:06:20 CDT