We use roles for both of these functions. We have a viewonly role which=20
contains only select privileges, and insert/update roles with insert and=20
update privileges for different areas, delete roles for different areas, an=
=20
admin role for administration tables, etc. We just check for a particular=
=20
role before allowing access to a screen, or may just remove a few buttons=20
so they can only view instead of attempting update.
At 08:16 AM 1/4/01 -0800, you wrote:
>If the different screens are in the application and not different=20
>applications then the user privilege is needing to be built into the=20
>application tables. We use roles to allow different users to access the=20
>database and application but an "access_level" field in the userid table=20
>to determine what each user can do in the application.
>If the screens are part of a package then you could grant exec privileges=
=20
>to different procedures in the package to different roles.
>ROR m=AA=BF=AAm
>
> >>> tekait11_at_bni.co.id 01/04/01 09:45AM >>>
>Well, I think I start to understand a little bit....
>
>The reason I ask this is because I just talked to a seminar participant, a
>database developer, and he said why I should care about the security
>subsystem, and build it as a part of my application. He said, I can just=
use
>the existing security subsystem from the database (using role &=
privileges).
>Usually, I create one or more
>tables to store user IDs, passwords, access levels, etc and then use a
>common access
>to the database. So, there were my application do the authentication.
>
>If I am not mistaken, based on Mark's comment, I can design roles &
>privileges to meet user requirement. I think it will work perfectly fine=
for
>PL/SQL in simple application. But if we develop a more complex application,
>using GUI screen, have some data manipulation processes before
>updating/inserting a record, this method make the inconvenience to user.
>Cause, he can read the record, calculate it, process I, process II, take
>several seconds (or minutes) the when it is time to update the record, the
>error says "not enough privileges".
>
>What I need in this scenario is user A can go to screen I, user B can go=
to
>screen II but not screen I, user C can go to both screen, etc....
>
>----- Original Message -----
>To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
>Sent: Thursday, January 04, 2001 5:50 PM
>
>
> > Use Roles & Priveliges. Create a privilege called level_one or=
something,
> > and grant the specific object/system priveliges that that level user
> > requires, then grant that role to the user. No extra tables required,=
and
> > saves a hell of a lot of time, as you don't need to grant each specific
> > privelige to each and every user, you just have one or maybe a few=
grants
>on
> > roles.
> >
> > HTH
> >
> > Mark
> >
> >
> > -----Original Message-----
> > Sent: Thursday, January 04, 2001 09:32
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Dear DBAs,
> >
> > I am working on an application and designing the security. I want to use
>the
> > existing Oracle security (user ID, password) without maintain or create
> > additional tables (if really possible). However, I need additional
> > information that will describe user's authority (i.e. user level 1 can=
do
>a
> > certain transaction while user level 2 can not).
> >
> > Does anybody know what practise to do this?
> >
> > THALIA (THanks A Lot In Advance)
> >
> > Y. Nosie
> >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Nosie
> > INET: tekait11_at_bni.co.id
> >
> > 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).
> >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Mark Leith
> > INET: mark_at_cool-tools.co.uk
> >
> > 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).
> >
>
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>--
>Author: Nosie
> INET: tekait11_at_bni.co.id
>
>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).
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>--
>Author: Ron Rogers
> INET: RROGERS_at_galottery.org
>
>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
Received on Thu Jan 04 2001 - 13:08:35 CST
