Database Reference
In-Depth Information
•
Open Door
: Developer testing simulates logging in as different individuals.
This isn't intended to be used as a public authentication scheme.
•
No Authentication
: This option is intended to allow all parts of the applica-
tion to be reachable without needing a user to log in.
Each application has its own set of authentication schemes managed as part of the
Shared Components of the application. Authentication schemes can be copied between
applications when needed. This ability to copy is especially useful when a custom au-
thentication scheme has been developed and is desired in more than one application.
The authentication schemes also utilize the APEX subscription framework to allow a
master copy to be applied to subscribers inside of a single workspace.
Custom Authentication Schemes
In the previous section, the script that was imported included definitions for tables,
triggers, and functions. You use those elements as part of your custom authentication
scheme. The key component of the authentication scheme is a function that compares
the given username and password to the stored values in the
USERS
table. If there is a
match, then the user is authenticated. You can review the database objects and PL/SQL
function code from the SQL Workshop for more details on how this is implemented.
Note
Although the
USERS
table contains a field named
PASSWORD
, it's not the ac-
tual password value; it's an encrypted hash of the password. Passwords should never be
stored as plain text.
Here's the process to follow to create a custom authentication scheme based on the
database objects just mentioned:
1.
Navigate to the
Shared Components
of the application.
2.
