Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: logon trigger - getting program version information of application connecting

Re: logon trigger - getting program version information of application connecting

From: Niall Litchfield <n-litchfield_at_audit-commission.gov.uk>
Date: Mon, 15 Mar 2004 10:18:32 -0000
Message-ID: <405582f8$0$3303$ed9e5944@reading.news.pipex.net>


Do the users have their own oracle accounts or is there one for the app. We have the same problem with the latter scenario and just change the db password and only distribute the password to new releases - done at install of new release time.

-- 
Niall Litchfield
Oracle DBA
Audit Commission UK
<OracleSupport-dropthis_at_shaw.ca> wrote in message
news:r3u950hr7h9vagbfo3idgou01kupqi0pqp_at_4ax.com...

> On Mon, 15 Mar 2004 00:10:57 -0000, "DJ" <nospamplease_at_goaway.com>
> wrote:
>
> >
> ><OracleSupport-dropthis_at_shaw.ca> wrote in message
> >news:kgq9509748l74vtg9r9kpma6if4ho68d0r_at_4ax.com...
> >> On Sun, 14 Mar 2004 15:08:45 +0000, Pete Finnigan
> >> <plsql_at_petefinnigan.com> wrote:
> >>
> >> >Hi
> >> >
> >> >have a look at my first newsletter on my website which discusses some
> >> >ideas on how to block SQL*Plus it may give you some ideas, its at
> >> >http://www.petefinnigan.com/newrecent.htm - one extra thought would be
> >> >to create an external procedure or use java in your logon trigger to
> >> >access the OS and read the size of the binary - This obviously would
> >> >depend on the binary being on the server - i guess it is probably on
the
> >> >client...:-(
> >> >
> >> >Another thought, if possible would be to use the client_identifier
field
> >> >set with the DBMS_SESSION.SET_IDENTIFIER or the client_info, module or
> >> >action fields set with dbms_application_info procedures. Any of these
> >> >fields can then be read in the logon trigger from v$session. The big
> >> >problem is getting the client to call these procedures first?? -
> >> >maybe..... if you cannot change the application your users must
execute
> >> >the application from a menu item or from a shortcut - you could
replace
> >> >the shortcut or menu with a call to a simple batch script that
executes
> >> >first a check on the binary and aborts or logs onto the database and
> >> >sets the version stuff as above and the db connection would abort if
its
> >> >wrong - the first option is best though just alter the menu or
shortcut
> >> >and abort if wrong binary and print a message to contact support.
> >> >
> >> >hth
> >> >
> >> >kind regards
> >> >
> >> >Pete
> >>
> >> Pete,
> >>
> >> Thanks for the link, but I've tried various incarnations of the rename
> >> application etc to no luck (among other things).
> >>
> >> This 3rd party application does indeed reside on the client and there
> >> are several "modules" that the user can run all which call the
> >> "security" module which in turn allows access to the database. I tried
> >> renaming the security exe itself and was able to differentiate between
> >> the versions, however this "broke" the other modules as they want to
> >> run the security executable, but couldn't because of the name change.
> >>
> >> I was hoping to somehow force the version information to be sent along
> >> with the executable name so I could extract it from v$session, but so
> >> far no luck. Doing checks from the client side has me faced with the
> >> same problem, if I miss machines during the upgrade / change, I'll
> >> still have the possible issue of a valid user being able to connect
> >> using the wrong version of the application.
> >>
> >> My main concern is the 10% or so machines that are laptops or are
> >> located at remote sites, as well as the "on vacation" staff that
> >> haven't turned on their workstation in 3 weeks. I'm pretty sure my
> >> team got the majority of standard networked clients, but those other
> >> machines could easily slip through the upgrade process altogether.
> >>
> >> I guess I'll find out this week what percentage of machines we were
> >> able to hit as my team just informed me the upgrade is complete.
> >>
> >> Anyway thanks for the input.
> >>
> >> Brad
> >
> >well sorry to day it, but you seem buggered - not my companys app is it
;-)
> >
>
>
> I hope not, though the company that wrote this app is well known.
>
> The sad thing is my team looks after several applications even worse
> than this particular one. Some of the commercial applications out
> there are just plain scary.
>
> Ciao,
>
> Brad
>
Received on Mon Mar 15 2004 - 04:18:32 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US