RE: Ids and passwords for application users

  If a common login is used (which is the case with most applications), dbms_application_info can be used to set the actual username in either the module or action. As long as the application is not using dbms_application_info to set both, you should be able to get the info from v$session.

Regards,
Denny

Quoting Jacques Kilchoer <Jacques.Kilchoer_at_quest.com>:

> I always preferred the option of having a userid for each person,
> because it
> makes it easier to match session to user. When you say userid
> "dwilliams"
> locking a table you know who to call, but if you see userid "app_user"
> you
> have to do some extra work to track the person down. From a developer
> point
> of view, it's easier to determine the name of the logged in user (use
> built-in "user" function) than it would be to find out the machine name
> /
> application name (select * from v$session).
> If you have only one username with a password hard-coded in the
> application,
> how do you plan on hiding the password from the user, or changing the
> password if it becomes compromised?
>
> > -----Original Message-----
> > From: DENNIS WILLIAMS [mailto:DWILLIAMS_at_LIFETOUCH.COM]
> >
> > Peter - Go with option #1 unless you relish a career as an
> > Oracle security
> > officer. With option #1 the developers can create some administrator
> > screens. Unless security is really, really critical.
> >
> > -----Original Message-----
> >
> > I am in the process of designing a small database which may have
> > as many as 250 to 300 users. We are reaching a stage where we need
> > to decide how we will control access to this database. As I see it
> > we have two options:
> >
> > 1. Provide a single hidden login for the entire application
> > and control
> > access to the applicaiton itself either by "roll your own" security
> or
> > using the operating system (UNIX) controls.
> >
> > 2. Create ids for the users in Oracle and grant them access
> > to the necessary tables using roles.
> >
> > Any opinions or alternate suggestions?
> >
> > Peter Schauss

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: groups_at_koovakattu.com

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).