I think the real issue is who is going to keep the usernames and passwords maintained. Is it you? Do you have that much spare time? Also, it can also be inefficient with everyone's time. Someone gets hired. Their supervisor sends you an email so you can create the userid. But wait, they forgot to tell you which functions the employee needs access to. So you email the supervisor back and wait for a reply. Then you complete the user signup. Then it turns out the supervisor misspelled the employee's name (people are so picky), so you get to remove what you did and repeat it again. Don't even get me started on how they never tell you when someone leaves the organization. And of course, there is the ever-popular "I forgot my password" requests. My point is that creating and maintaining individual Oracle accounts can be very time-consuming and put you, the DBA, in the middle of a lot of application issues you really wouldn't need to be concerned about otherwise. For some systems you will need to create and maintain individual Oracle accounts. But my experience has been that if the application can maintain the security and populate a table with logins, this saves everyone a lot of time and trouble. Often the application security can be handed off to a non-I.S. person, or even distributed among several people. These people probably understand the user community and the application requirements much better than a DBA does. Sure, on those rare occasions when you need to find a user, it is an additional step, but if the system is running pretty well that doesn't occur that often. As for hiding/maintaining the underlying password(s), normally these will be buried in the application. And it sure is easier to change the password in one location and recompile the application. Anyway, these have been my experiences with the applications I've worked with. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED]
-----Original Message----- Sent: Tuesday, July 30, 2002 7:53 PM To: Multiple recipients of list ORACLE-L > -----Original Message----- > From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ] > > 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. Sure, but I will repeat what I said before: a) It's easier to write code if the user is determined by the Oracle userid rather than by v$session.client_info. Trigger example: create trigger orders_set_user before insert or update on orders for each row begin :new.last_upd_user := user ; end orders_set_user ; / b) How do you plan on hiding the password from the user, or, more importantly, changing the password if it becomes compromised? -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
