Re: Different way of maintaining users?

If your aim is to block the SQL*Plus user from seeing data one of the following can be tried (though i myself have never attempted them) 1. VPD (attach a predicate where rownum < 1 OR where 1=2 that way no row will get selected)
2. Use Product user profile and try to block SELECT/INSERT/DELETE/UPDATE

hth
GovindanK

On Fri, 14 Oct 2005 15:10:14 -0400, "Vanessa A. Simmons" <vsimmons_at_hes.hmc.psu.edu> said:
> We are considering a change to the way our users access the database and
> our applications. We would like to make sure that users are getting to
> the data through the applications only and not using external tools
> (i.e. SQL*Plus) to access the database directly with the hopes that this
> will help us to further secure our databases. In this scenario, we would
> create a high-level user which would be the data source user (we're
> using Cold Fusion for our application front-end) that would be able to
> run any query on behalf of the user "logged in" to the application.
> However, each user would not have his/her own DB account that requires
> role and password maintenance. Instead, the programmers would create a
> user and role table in the database that would hold this information
> (including encrypted passwords) so that the users do not have individual
> access to the database. That would push a lot of the user maintenance
> that I deal with on a daily basis to either our programmers or a help
> desk technician.
>
> My question is whether or not this is a sound plan and if you have any
> concerns about problems we might encounter if we decide to go this
> route? Has anyone else done something similar in their environment?

--
http://www.freelists.org/webpage/oracle-l