Database Reference
In-Depth Information
:= sys.f_get_off in our logon trigger procedure, p_appver_logon , Listing 10-14? It is a nice idea that
won't work. The f_get_off function shown in Listing 10-15 could accomplish the task for us; however,
Oracle Database does not allow us to kill the current session.
Listing 10-15. Non-functional Kill Switch, f_get_off
CREATE OR REPLACE FUNCTION sys.f_get_off
RETURN VARCHAR2
AS
PRAGMA AUTONOMOUS_TRANSACTION;
p_sid v$session.SID%TYPE;
p_serial v$session.serial#%TYPE;
BEGIN
p_sid := SYS_CONTEXT( 'USERENV', 'SID' );
SELECT serial# INTO p_serial
FROM v$session
WHERE sid = p_sid;
EXECUTE IMMEDIATE 'ALTER SYSTEM KILL SESSION ''' ||
p_sid || ',' || p_serial || '''';
RETURN 'OFF';
END f_get_off;
GRANT EXECUTE ON sys.f_get_off TO appsec;
Note You can find Listing 10-15's function in the file named Chapter10/Sys.sql .
The heart of the function is in the EXECUTE IMMEDIATE command. An alternative along these lines
that would work would be if we inserted the SID and SERIAL# to be killed into a table. Then using an
independent, scheduled task, read the table and kill the sessions, then delete the records from the table.
Anyway, manhandling in the most direct way is not going to work. Just as well, because our call in
p_appver_logon to RAISE_APPLICATION_ERROR does the same thing. Because we are in a logon trigger,
when we raise an exception, the logon fails.
Function to Find Database User
There is a function that we have, for use in the appver logon trigger procedure, f_is_user , which tests
whether the OS user is also a database user. This is an important test, because it enforces a portion of
our SSO requirements—if we haven't created an Oracle user with the same name as this person's
operating system user name, then he cannot use our applications. This function, Listing 10-16, will be
added to the package, appsec_only_pkg .
 
Search WWH ::




Custom Search