Using Invoker's Rights Versus Definer's Rights (AUTHID Clause)

END;

/

In Example 8–11, the choice of which instance to call is made at compile time. In Example 8–12, this choice is made dynamically. We declare v as an instance of super_t, but because we assign a value of sub_t to it, the appropriate instance of the function is called. This feature is known as dynamic dispatch.

Example 8–12 Resolving PL/SQL Functions With Inheritance Dynamically

CREATE TYPE super_t AS OBJECT

(n NUMBER, MEMBER FUNCTION func RETURN NUMBER) NOT final;

/

CREATE TYPE BODY super_t AS

MEMBER FUNCTION func RETURN NUMBER IS BEGIN RETURN 1; END; END;

/

CREATE OR REPLACE TYPE sub_t UNDER super_t (n2 NUMBER,

OVERRIDING MEMBER FUNCTION func RETURN NUMBER) NOT final;

/

CREATE TYPE BODY sub_t AS

OVERRIDING MEMBER FUNCTION func RETURN NUMBER IS BEGIN RETURN 2; END; END;

/

CREATE OR REPLACE TYPE final_t UNDER sub_t (n3 NUMBER);

/

DECLARE

v super_t := final_t(1,2,3); BEGIN

DBMS_OUTPUT.PUT_LINE(v.func); -- prints 2 END;

/

Using Invoker's Rights Versus Definer's Rights (AUTHID Clause)

By default, stored procedures and SQL methods execute with the privileges of their owner, not their current user. Such definer's rights subprograms are bound to the schema in which they reside, allowing you to refer to objects in the same schema without qualifying their names. For example, if schemas HR and OE both have a table called departments, a procedure owned by HR can refer to departments rather than HR.departments. If user OE calls HR's procedure, the procedure still accesses the departments table owned by HR.

If you compile the same procedure in both schemas, you can define the schema name as a variable in SQL*Plus and refer to the table like &schema..departments. The code is portable, but if you change it, you must recompile it in each schema.

A more maintainable way is to use the AUTHID clause, which makes stored procedures and SQL methods execute with the privileges and schema context of the calling user. You can create one instance of the procedure, and many users can call it to access their own data.

Such invoker's rights subprograms are not bound to a particular schema. The following version of procedure create_dept executes with the privileges of the calling user and inserts rows into that user's departments table:

Using PL/SQL Subprograms 8-15

Using Invoker's Rights Versus Definer's Rights (AUTHID Clause)

Example 8–13 Specifying Invoker's Rights With a Procedure

CREATE OR REPLACE PROCEDURE create_dept ( v_deptno NUMBER,

v_dname VARCHAR2,

v_mgr NUMBER,

v_loc NUMBER)

AUTHID CURRENT_USER AS BEGIN

INSERT INTO departments VALUES (v_deptno, v_dname, v_mgr, v_loc); END;

/

CALL create_dept(44, 'Information Technology', 200, 1700);

Advantages of Invoker's Rights

Invoker's rights subprograms let you reuse code and centralize application logic. They are especially useful in applications that store data using identical tables in different schemas. All the schemas in one instance can call procedures owned by a central schema. You can even have schemas in different instances call centralized procedures using a database link.

Consider a company that uses a stored procedure to analyze sales. If the company has several schemas, each with a similar SALES table, normally it would also need several copies of the stored procedure, one in each schema.

To solve the problem, the company installs an invoker's rights version of the stored procedure in a central schema. Now, all the other schemas can call the same procedure, which queries the appropriate to SALES table in each case.

You can restrict access to sensitive data by calling from an invoker's rights subprogram to a definer's rights subprogram that queries or updates the table containing the sensitive data. Although multiple users can call the invoker's rights subprogram, they do not have direct access to the sensitive data.

Specifying the Privileges for a Subprogram with the AUTHID Clause

To implement invoker's rights, use the AUTHID clause, which specifies whether a subprogram executes with the privileges of its owner or its current user. It also specifies whether external references (that is, references to objects outside the subprogram) are resolved in the schema of the owner or the current user.

The AUTHID clause is allowed only in the header of a standalone subprogram, a package spec, or an object type spec. In the CREATE FUNCTION, CREATE PROCEDURE, CREATE PACKAGE, or CREATE TYPE statement, you can include either

AUTHID CURRENT_USER or AUTHID DEFINER immediately before the IS or AS keyword that begins the declaration section.

DEFINER is the default option. In a package or object type, the AUTHID clause applies to all subprograms.

Most supplied PL/SQL packages (such as DBMS_LOB, DBMS_PIPE, DBMS_ROWID, DBMS_SQL, and UTL_REF) are invoker's rights packages.

Who Is the Current User During Subprogram Execution?

In a sequence of calls, whenever control is inside an invoker's rights subprogram, the current user is the session user. When a definer's rights subprogram is called, the

8-16 Oracle Database PL/SQL User’s Guide and Reference