|
|
|
Использование DBMS_SESSION.Set_Context и Sys_Context
|
|||
|---|---|---|---|
|
#18+
В версии Oracle 8.1.5 есть функция Sys_Context и функция из пакета DBMS_SESSION.Set_Context. В документации к Oracle, топик: Oracle8i Application Developer's Guide - Fundamentals Release 8.1.5 A68003-01 есть описание использования данных функций, но к сожалению не очень понятно для чего они нужны в прикладном смысле. Если со стандартными параметрами функции Sys_Context боле менее ясно - возвращаются значения ассоциированные с пространством имен текущего пользователя, то не совсем понятно зачем нужны создаваемые функцией Create_Context пространства имен и для чего они используются в сочетании с DBMS_SESSION.Set_Context (в выше приведенном топике). Со зверским уважением Black Dragon ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 22:20:03 |
|
||
|
Использование DBMS_SESSION.Set_Context и Sys_Context
|
|||
|---|---|---|---|
|
#18+
2 Black Dragon: SET_CONTEXT is mostly used in fine grained access (RLS - row level security). For example, application APP always logs in to database as APPOWNER, but depending on application user it needs to provide different row level access. First thing we need to do is to register application namespace using CREATE CONTEXT statement. So we create a package owned by APPOWNER, for example, APP_CONTEXT which sets context for each application user. Context namespace is, for example, APP_NAMESPACE. Package matches application user against employee table and set context to dbms_session.set_context( 'APP_NAMESPACE', 'ROLE', 'EMP' ); if he/she is a regular employee or dbms_session.set_context( 'APP_NAMESPACE', 'ROLE', 'MRG' ); if he/she is a manager. Now we can register namespace via CREATE OR REPLACE CONTEXT APP_NAMESPACE USING APPOWNER.APP_CONTEXT / Now application can call the package (which will set the context) at login time. Next step is to create predicate functions. So we create a package owned by APPOWNER, for example APP_SECURITY which has a function SECURE_ACCESS( OBJ_OWNER VARCHAR2, OBJ_NAME VARCHAR2). Now for every object we want to restrict row level access to that function would return a predicate - a condition string which will be added to WHERE clause (assuming corresponding RLS policy is added) every time application users will be accessing database object OBJ_OWNER.OBJ_NAME. Assume, for example, famous EMP table owner by SCOTT. If session context is 'APP_NAMESPACE', 'ROLE', 'EMP' function will return 'empno = '||app-user-empno. If session context is 'APP_NAMESPACE', 'ROLE', 'MGR' function will return 'empno = '||app-user-empno OR empno in (select empno from emp where mgr= ' ||app-user-empno || ')'. Now all we need is dbms_rls.add_policy( 'SCOTT','EMP','EMP_POLICY','APPOWNER', 'APP_SECURITY.SECURE_ACCESS', 'SELECT', true, true ); This way when application APP selects from table SCOTT.EMP a corresponding condition will be automatically added to SELECT statement limiting application APP user ability to see table data. SY. P.S. The above was a very high level explanation just to give you basic idea. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2003, 01:31:47 |
|
||
|
|

start [/forum/topic.php?fid=52&gotonew=1&tid=1989963]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
227ms |
get topic data: |
11ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 230ms |
| total: | 567ms |

| 0 / 0 |
