Help
- Thread starter dananiev
- Start date
One idea:
All tables would have to be read-only. i.e. only select rights granted.
All change access would have to be via procedures/packages and these would internally could look at the program used for the current session (using the v$session system view).
[This message has been edited by jpickup (edited 13 December 2000).]
All tables would have to be read-only. i.e. only select rights granted.
All change access would have to be via procedures/packages and these would internally could look at the program used for the current session (using the v$session system view).
[This message has been edited by jpickup (edited 13 December 2000).]
Another idea: create an application role that is granted the update privileges, and protect it with a password that only your application "knows":
SQL> create role myapp_role identified by secret;
SQL> grant insert, update, delete on mytable to myapp_role;
SQL> grant myapp_role to scott;
When scott connects to the database, this role is disabled for the session and he cannot update mytable. When scott connects through your application, it must first enable the role for the application session:
set role myapp identified by secret
The trick is that no one must know this password, except your application.
------------------
Marco Kalter
Allround Automations
SQL> create role myapp_role identified by secret;
SQL> grant insert, update, delete on mytable to myapp_role;
SQL> grant myapp_role to scott;
When scott connects to the database, this role is disabled for the session and he cannot update mytable. When scott connects through your application, it must first enable the role for the application session:
set role myapp identified by secret
The trick is that no one must know this password, except your application.
------------------
Marco Kalter
Allround Automations
Similar threads
- Discussion
- Discussion
