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

<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 ;-) Received on Sun Mar 14 2004 - 18:10:57 CST