Defining a Dynamic Policy
In the previous sections, I talked about a policy that returns a predicate string that is constant—for example, SAL <= 1500. In real life, such a scenario is not very common, except in some specialized applications such as goods warehouses. In most cases, you will need to build a filter based on the user issuing the query. For instance, the HR application may require that users see only their own records, not all records in a table. This is a dynamic requirement, as it needs to be evaluated for each employee who logs in. The policy function can be rewritten as follows.
1 CREATE OR REPLACE FUNCTION authorized_emps ( 2 p_schema_name IN VARCHAR2, 3 p_object_name IN VARCHAR2 4 ) 5 RETURN VARCHAR2 6 IS 7 l_return_val VARCHAR2 (2000); 8 BEGIN 9 l_return_val := 'ENAME = USER'; 10 RETURN l_return_val; 11 END; 12 /
In line 9, the predicate will compare the ENAME column with the USER—that is, the name of the currently logged-in user. If the user Martin (remember that Martin is the name of an employee in the table EMP) logs in and selects from the table, he sees only one row—his own.
SQL>CONN martin/martin
Connected. SQL>SELECT * FROM hr.emp;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO ------ ---------- --------- ------ --------- ------ ------ ------ 7654 MARTIN SALESMAN 7698 28-SEP-81 1,250 1,400 30
Now let’s expand this model to let Martin show more records—not just his own, but his entire department’s records. The policy function now becomes the following.
1 ...
Get Oracle PL/SQL for DBAs now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.