Using Database Session-Based Application Contexts
Step 6: Remove the Components for This Example 1.
Log on as SYS and connect using AS SYSDBA. CONNECT SYS/AS SYSDBA Enter password: password
2.
Drop the users sysadmin_ctx and lozer: DROP USER sysadmin_ctx CASCADE; DROP USER lozer CASCADE;
3.
Drop the application context. DROP CONTEXT empno_ctx;
Remember that even though sysadmin_ctx created the application context, it is owned by the SYS schema. 4.
If you want, lock and expire SCOTT, unless other users want to use this popular account: ALTER USER SCOTT PASSWORD EXPIRE ACCOUNT LOCK;
After you have removed the application context and its associated package and trigger, users should be able to log on to the database instance again.
Initializing Database Session-Based Application Contexts Externally When you initialize a database session-based application context externally, you specify a special type of namespace that accepts the initialization of attribute values from external resources and then stores them in the local user session. Initializing an application context externally enhances performance because it is stored in the UGA and enables the automatic propagation of attributes from one session to another. Connected user database links are supported only by application contexts initialized from OCI-based external sources. This section contains these topics: ■
Obtaining Default Values from Users
■
Obtaining Values from Other External Resources
■
Initializing Application Context Values from a Middle-Tier Server
Obtaining Default Values from Users Sometimes you need the default values from users. Initially, these default values may be hints or preferences, and then after validation, they become trusted contexts. Similarly, it may be more convenient for clients to initialize some default values, and then rely on a login event trigger or applications to validate the values. For job queues, the job submission routine records the context being set at the time the job is submitted, and restores it when executing the batched job. To maintain the integrity of the context, job queues cannot bypass the designated PL/SQL package to set the context. Rather, the externally initialized application context accepts initialization of context values from the job queue process. Automatic propagation of context to a remote session may create security problems. Developers or administrators can effectively handle the context that takes default values from resources other than the designated PL/SQL procedure by using logon triggers to reset the context when users log in.
7-14
Oracle Database Security Guide