Pro Oracle Application Express 4

For your convenience Apress has placed some of the front matter material after the index. Please use the Bookmarks and ...

Author: Tim Fox | John Scott | Scott Spendolini

45 downloads 1759 Views 27MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

For your convenience Apress has placed some of the front matter material after the index. Please use the Bookmarks and Contents at a Glance links to access them.

Contents at a Glance  About the Authors................................................................................................. xv  About the Technical Reviewer ............................................................................ xvii  Acknowledgments ............................................................................................. xviii  Foreword ............................................................................................................. xix  Introduction ......................................................................................................... xxi  Chapter 1: Development Best Practices .................................................................1  Chapter 2: Authentication and User Management ...............................................41  Chapter 3: Conditions and Authorization Schemes ............................................101  Chapter 4: Data Security.....................................................................................137  Chapter 5: Navigation and Layout.......................................................................187  Chapter 6: Reports and Charts............................................................................241  Chapter 7: Dynamic Actions ...............................................................................299  Chapter 8: Websheets .........................................................................................331  Chapter 9: Reporting and Printing ......................................................................367  Chapter 10: Themes and Templates ...................................................................409  Chapter 11: Localization Issues..........................................................................455  Chapter 12: Plug-ins ...........................................................................................495  Chapter 13: Web Services...................................................................................527  Chapter 14: Performance and Scalability ...........................................................559  Chapter 15: Production Issues............................................................................599  Chapter 16: APEX Dictionary...............................................................................647  Index ...................................................................................................................689

iv

Introduction If you’re new to APEX development, prepare yourself for one of the most productive tools available for Oracle application development. The speed with which you can create fully functional, secure, webbased applications is truly astounding, especially when compared to using a tool like Java. If you are used to writing procedural or object-oriented code, you may find APEX’s declarative development methodology a little challenging at first, but the learning curve is not significant. When you consider that you only need an Oracle database to get started, the barriers to beginning APEX development are minimal. The first edition of this book, Pro Oracle Application Express, was written in 2008 using APEX 3.2. In 2010, Oracle released APEX 4.0, which included a significant number of new features along with a major upgrade of the development environment’s user interface. Along with the much improved look and feel, Oracle included several Web 2.0 features like Dynamic Actions, Plug-ins, and RESTFul web service support. Prior to APEX 4.0, you could implement the newest web features, but it usually required custom coding. With APEX 4.0, you can use the familiar declarative development techniques to add an Ajax feature, for example. The inclusion of these significant new features obviated the need for a revision of the original book. In general, APEX 4.0 lets you create professional looking, feature-laden applications with less effort than ever before.

xxi

CHAPTER 1 



Development Best Practices Oracle Application Express (APEX) makes it extremely easy to quickly prototype and develop a web application. However, as a software developer, you’re probably aware that speed of development is only one of a number of criteria that will contribute to the perceived success (or failure) of your project. Of course, perceptions about a project’s success can vary. For example, the people who encounter a typical project might include developers, testers, managers, production support, and end users. The developers may feel that the project was a success because development went quickly, Production support might feel like the project was a failure because no one has a clear strategy for performing application upgrades. The end users may dread using the application because it runs incredibly slowly. Clearly, for the project to be considered a success, you need to satisfy the expectations of all these people (or as many as you reasonably can). Ideally, you should strive for an application that has the following characteristics: • Easy to develop • Easy to deploy and upgrade • Easy to maintain and debug • Enjoyable for end users to use • Fast enough for the users’ requirements • Stable from the end users’ perspective • Secure enough to protect your data from unauthorized access You should never end up feeling like developing, deploying, maintaining, or (even worse) using the application is seen as a chore. Each of these areas can often benefit from the adoption of some best practices to ensure that everyone involved sees your application as a success. Chapter 1 is the best place to introduce best-practice techniques, since they should form the foundation of every significant development project you undertake. You can certainly create applications without using any of the techniques we’ll discuss, but adopting techniques like these will make your job as a developer easier, and your applications will be considerably more successful.

1

CHAPTER 1  DEVELOPMENT BEST PRACTICES

APEX Installation Decisions This book will not cover the details of installing APEX version 4.0, since that information is already bundled with the product, as well as discussed in detail in several online resources. It is worth mentioning, however, that APEX 4.0 supports another connection type via the Oracle Application Express Listener. The APEX Listener is a Java-based web server that is certified to run under Web Logic, Tomcat, OC4J with Oracle WebLogic Server, OC4J, and Oracle Glassfish. Indeed, many people enjoy using APEX without bothering with installation, either because someone else has installed it for them or they are using a hosted environment (such as the public Oracle apex.oracle.com site or one of the commercial providers such as Shellprompt). Others use Oracle Database Express Edition (XE), a free edition of the database that includes a preinstalled version of APEX. However, if you are installing APEX, one important decision is which tablespace to use for the product. The installer usually defaults to installing APEX into the SYSAUX tablespace, and if you’re using the 11g version of the database, the SYSAUX tablespace will be selected by default. I highly recommend that instead of using SYSAUX you create a dedicated tablespace that you’ll use specifically for the APEX database objects and metadata. By using a dedicated tablespace, you can gain a far greater degree of control and flexibility over the administration of the APEX environment. For example, should it become necessary to recover the tablespace using point-in-time recovery from an Oracle Recovery Manager (RMAN) backup, you’ll be confident that you haven’t affected any other database components, like AWR (which may not be the case if you install into SYSAUX). Installing into a separate, dedicated tablespace also allows the database administrator (DBA) to make decisions about where that dedicated tablespace should be stored on disk (to reduce contention), control the storage growth of the tablespace, and perhaps also take advantage of advanced Oracle features, such as transportable tablespaces to quickly move the tablespace to another database instance.

Application Development Considerations The decisions related to how to create and organize your application within the APEX and database environment will greatly affect how easily you’ll be able to deploy and migrate your application later on. By structuring your development environment in a logical and organized way, you’ll encounter far fewer problems when your application needs to be deployed or updated to your live environment.

Users and Administrators When APEX is installed, an Application Express instance administrator is created. You can connect to APEX as this instance administrator in two ways: •

Connect to one of the following URL’s:

•

PL/SQL Plugin: http://server:port/pls/apex/apex_admin

•

APEX Listener or EPG: http://server:port/apex/apex_admin

Use the username ADMIN and the password you used when you installed the product.

2


•

Connect to the same URL you’d use to log into any workspace, such as http://server:port/pls/apex/apex_login, and use INTERNAL as the workspace and ADMIN as the username with the password you used when you installed the product.

Including the instance administrator, four different types of users exist for APEX: Application Express instance administrator: This is the user you’ll use to administer the APEX installation. The instance administrator can connect only to the INTERNAL workspace to perform administration tasks, such as creating workspaces and users, monitoring activity, and managing the APEX service. Instance administrators can’t create any applications themselves; they must create workspaces and other users for applications to be created. The instance administrator can create workspace administrators, developers, and built-in users for any of the workspaces. Workspace administrator: A workspace administrator is responsible for the administration of a particular workspace. As a workspace administrator, you are able to create developers and users for that workspace, and create applications. Workspace administrators can also log into any application within the same workspace that uses APEX account credentials. Application developer: Application developers are created within a particular workspace by workspace administrators. They can create and maintain an application within that workspace. They can’t log in to other workspaces, but they are able to log in to any application within the same workspace that uses APEX account credentials. Application user: Application users can take two forms. They can be created and managed within the APEX environment and are then known as built-in users (or cookie users). Alternatively, they can be created and managed outside the APEX environment; for example, they could be stored within a database table or as part of a Lightweight Directory Access Protocol (LDAP) directory. Built-in users are able to log in to any application within the same workspace that uses APEX account credentials. For small projects with a single developer, it is quite possible to perform all application development as the workspace administrator. However, for any development that uses two or more developers, it’s best to create a specific developer account for each physical developer, since this lets you use features such as page-locking, as well as track changes to the application at the developer level. Although the workspace administrator could be one of the physical developers, a better idea is to create a developer account to use for development. Use the workspace administrator account only when necessary to perform administration duties.

Workspaces and Schemas When you create an application in APEX, you must select a schema as the default parsing schema. In other words, if you built a report that issued a query like this:

3


select empno, ename from emp; the query would use the emp table in the schema you selected as the parsing schema when you created your application. If you wanted to access an object in a different schema, you could prefix the object name with the schema name, like this: select empno, ename from payroll.emp; Because the application will be executed using the parsing schema (and its privileges), accessing objects in other schemas requires that the appropriate privileges are granted to the parsing schema. Objects in other schemas can also be accessed via synonyms or a view, which effectively hides the schema and enables you to reference the object without needing to specify the schema name yourself.

Choosing a Parsing Schema The schemas assigned to the workspace you are currently logged into define the choice of schemas that can be used as the parsing schema. When you create a workspace (as an APEX administrator), you must specify whether to use an existing schema or create a new one, as shown in Figure 1-1. If no other schemas are assigned to the workspace, you will be able to select only this schema as the parsing schema when you create your application.

Figure 1-1. Creating a new workspace This means that if you already have an existing schema with a lot of objects you’d like to access, you can select that schema. Then, any applications that are created within the schema will be able to access those schema objects directly. This way, you can create an application in APEX that provides a front end to existing data very quickly. Although you can select only a single schema during the provisioning of the workspace, extra schemas can be assigned to the schema later on. After these additional schemas have been assigned to the workspace, they are available to workspace developers to use as the default parsing schema when they create an application within that workspace. If you choose to create a new schema during the provisioning of the workspace, a new tablespace and corresponding datafile will be created for that schema automatically. The disadvantage is that the tablespace and datafile will have nondescriptive names, such as APEX_1400423609989676 and APEX_1400423609989676.dbf. Moreover, if you later decide to remove the workspace, that tablespace and datafile will not be deleted. If you regularly provision and delete a lot of workspaces, you can end up with

4


many tablespaces and datafiles cluttering up your disk (and perhaps being unnecessarily included in your backups). For small developments or evaluation, it may be fine to create a new schema through the APEX wizard. However, from a maintenance point of view, this approach often increases the difficulty in correlating schemas, tablespaces, datafiles, and workspaces because of the nondescriptive names. While this may not be a primary concern to you as a developer, it can be critical to how quickly the DBA is able to restore your schema from a backup if necessary. Generally, for larger developments, if you are not using an existing schema, you may find it beneficial to manually create the tablespace and schema yourself, using a tool such as Enterprise Manager. For example, you can create a tablespace called APEXDEMO, which has a single datafile named APEXDEMO01.dbf that’s allowed to grow to 2GB. You can then create a user APEXDEMO that has the APEXDEMO tablespace as its default tablespace. Figure 1-2 shows how the schema would look after being created in Enterprise Manager.

Figure 1-2. Creating a schema in Enterprise Manager You could now create a workspace named APEXDEMO and select the APEXDEMO schema you just created in Enterprise Manager, as shown in Figure 1-3. This naming scheme ties together your workspace with the underlying schema and related tablespace and datafiles. If you should accidentally drop some tables (forgetting for the moment about the recycle bin in Oracle Database 10g / 11g), you can use RMAN to recover them easily, since their schema and tablespace will be obvious.

Figure 1-3. Creating a workspace using an existing schema Although the APEX administrator can view reports that show which schemas and tablespaces particular workspaces are using, adopting a sensible naming convention makes it easier to get this information. For example, the DBA could look at a tablespace called APEXDEMO and be able to understand the purpose of that tablespace, which would not be clear from a generic tablespace name like APEX_1400423609989676.

5


 Note Naming and coding standards can be extremely subjective. For example, some people may prefer to name the tablespace as APEXDEMO_TS while others prefer TS_APEXDEMO. If you already have an existing policy that details how you should name database objects, it makes sense to adopt that same policy for your development with APEX. If you do not currently have a policy in place, you should consider adopting one. The standards policy you use should be detailed enough to aid you in your work, but not so draconian that it actually hinders you.

Once the workspace is provisioned, additional schemas can be assigned to it. For example, you can create an APEXDEMO_TEST schema in Enterprise Manager, log in as the Application Express instance administrator, choose Manage WorkspacesManage Workspace to Schema Assignments, and select that schema, as shown in Figure 1-4.

Figure 1-4. Adding a schema to a workspace

Controlling Access to New Schemas Now the workspace administrator can specify which application developers can use the new schema (or, indeed, any of the assigned schemas). Figure 1-5 shows an example of a new developer account being created. By default, the developer will be able to access both schemas (APEXDEMO and APEXDEMO_TEST), since both schemas have been assigned to this workspace.

6


Figure 1-5. Creating a new developer with access to all assigned schemas When this developer logs into the workspace, he or she can see the list of schemas that are available by clicking on the AdministrationManage Instance menus, as shown in Figure 1-6. Any application this developer creates can use any of the available schemas as its default parsing schema, as shown in Figure 1-7.

7


Figure 1-6. Schemas available to the developer

Figure 1-7. Selecting a default parsing schema for an application

8


Creating Workspaces Generally, workspaces should be used to group together applications that are related. In other words, if you have a number of developers collaborating on applications that are related to each other and operate on the same data and schemas, ideally you’d create a workspace specifically for those applications. It is possible, using multiple schemas assigned to a workspace, to establish a development/testing/live environment all within the same workspace. For example, you could create a single workspace that has a schema for development, a schema for testing, and a schema for live objects and data. You could then have three copies of your application: one pointing to the development schema, one to the testing schema, and one to the live schema. However, with this approach, it is all too easy to become confused about which schema you are operating in, with potentially disastrous effects. It’s best to create separate workspaces for development, testing, and live environments. This forces you to specifically log in to an environment, and helps to minimize the risk of making application or schema changes in the wrong environment. The APEX environment helpfully displays which workspace you are logged in to (and which user you are logged in as), so it definitely pays to double-check this information before you perform any drastic operations. You also need to consider how the development, testing, and production environments will be staged. You may have each environment running on a different database instance (for example, a development instance, a testing instance, and a production instance). If you have only one database instance, it is possible to have the three (or two if you choose to forgo the testing environment!) environments all installed on the same database instance.

Application Deployment An APEX application consists of three main components: •

The APEX application itself

•

Any external images and files (such as CSS files), stored in the web server file system

•

Database objects and data contained in the schema

The definition of the application itself—that is, the metadata that represents the pages, branches, processing logic, and so on—is stored in the schema that was created when the product was installed. This is quite distinct from the database objects on which your application performs operations, which are the database objects that reside in the parsing schema of your application and any other schemas that your application accesses. In order to deploy your application from one database to another (where APEX has already been installed), you need to deploy the application definition as well as any database objects on which it is depends. You also need to deploy any static files (CSS files, images, and so on).

Deploying Workspaces When moving an application from one APEX instance to another (instance here refers to a database with the APEX software installed), you need to have created the workspace on the destination instance. The instance administrator can choose to either create the workspace manually or export the existing workspace from the source instance. Exporting the workspace creates a file containing the SQL needed to re-create that workspace, and the instance administrator can then import that SQL file to the

9


destination instance. Figure 1-8 shows the APEXDEMO workspace being exported. Note that you can specify a file format to use (either UNIX or DOS), which will determine the newline sequence used in the file.

Figure 1-8. Exporting a workspace The advantage of using a workspace export file is that this also re-creates all the users and developers created within that workspace, so it’s a quick way of migrating all the existing users (and their permissions) to a new server. It also demonstrates an advantage of using the built-in users. If you use another method to authenticate your users, you’ll need to handle their migration manually. Listing 1-1 shows the contents of the file that is created by exporting the APEXDEMO workspace. Listing 1-1. Contents of a Workspace Export File set serveroutput on size 1000000 set feedback off -- Company, user group and user export -- Generated 2006.07.17 12:58:25 by ADMIN -- This script can be run in sqlplus as the owner of the Oracle flows engine. begin wwv_flow_security.g_security_group_id := 1635127392255802; end; / ----------------- W O R K S P A C E -- Creating a workspace will not create database schemas or objects. -- This API will cause only meta data inserts. prompt Creating workspace APEXDEMO... begin wwv_flow_fnd_user_api.create_company ( p_id => 1635220613255830, p_provisioning_company_id => 1635127392255802, p_short_name => 'APEXDEMO', p_first_schema_provisioned=> 'APEXDEMO', p_company_schemas => 'APEXDEMO:APEXDEMO_TEST'); end;

10


/ -------------------------------- G R O U P S -prompt Creating Groups... ----------------- U S E R S -- User repository for use with apex cookie based authenticaion. -prompt Creating Users... begin wwv_flow_fnd_user_api.create_fnd_user ( p_user_id => '1428202658421752', p_user_name => 'ADMIN', p_first_name => '', p_last_name => '', p_description => '', p_email_address=> '[email protected]', p_web_password => '1E6287A65491647783288E3C9E1A87D1', p_web_password_format => 'HEX_ENCODED_DIGEST_V2', p_group_ids => '', p_developer_privs=> 'ADMIN:CREATE:DATA_LOADER:EDIT:HELP:MONITOR:SQL', p_default_schema=> 'APEXDEMO', p_account_locked=> 'N', p_account_expiry=> to_date('201011011826','YYYYMMDDHH24MI'), p_failed_access_attempts=> 0, p_change_password_on_first_use=> 'Y', p_first_password_use_occurred=> 'N', p_allow_app_building_yn=> 'Y', p_allow_sql_workshop_yn=> 'Y', p_allow_websheet_dev_yn=> 'Y', p_allow_team_development_yn=> 'Y', p_allow_access_to_schemas => ''); end; / begin wwv_flow_fnd_user_api.create_fnd_user ( p_user_id => '1437223003555234', p_user_name => 'TGF', p_first_name => '', p_last_name => '', p_description => '', p_email_address=> '[email protected]', p_web_password => 'D72DA6B4C47475A502A29CA604ACCCBC', p_web_password_format => 'HEX_ENCODED_DIGEST_V2', p_group_ids => '', p_developer_privs=> 'CREATE:EDIT:HELP:MONITOR:SQL:MONITOR:DATA_LOADER', p_default_schema=> 'APEXDEMO', p_account_locked=> 'N', p_account_expiry=> to_date('201011011848','YYYYMMDDHH24MI'), p_failed_access_attempts=> 0,

11


p_change_password_on_first_use=> 'N', p_first_password_use_occurred=> 'N', p_allow_app_building_yn=> 'Y', p_allow_sql_workshop_yn=> 'Y', p_allow_websheet_dev_yn=> 'N', p_allow_team_development_yn=> 'Y', p_allow_access_to_schemas => ''); end; When possible, you should use workspace exports. They enable you to rapidly create a copy of an existing workspace and reduce the chance that you’ll forget to create a particular user or developer.

 Note Since the export file is a series of Data Definition Language (DDL) statements, it can be edited, such as to change the name of the workspace. However, you really shouldn’t do this unless you have been specifically advised to do so by Oracle.

Deploying Applications An application developer (or workspace administrator) can export an application from the Application Builder interface. This creates a file similar to the workspace export file, in that the file will contain all the statements necessary to create the metadata required for the application. However, the application export file does not contain the DDL to create any of the database objects your application uses, nor does the application export file contain any data from the database objects that your application uses. Such data would normally be handled with specialized data-loading tools, such as the import and export utilities, or copied over a database link. You can use the APEX export options, shown in Figure 1-9, to affect the file that is created. For the most part, you won’t need to change application export settings. However, you should understand what each of these options do. Here are descriptions of some of the more useful options: File Format: This allows you to specify whether you want to use a DOS or UNIX format. Your choice will affect which newline sequences will be used in the resulting export file. Owner Override: This lets the owner of an application specify that a different schema should be used rather than the one that is currently specified. It allows you to import the schema into a workspace that’s completely different from the workspace from which the application was exported. Build Status Override: This lets you specify whether the resulting export file will contain an application that developers can access (Run and Build Application) or one that only end users can access (Run Application Only). As of __ minutes ago: This allows you to export an application as it existed some time ago. For example, you could export an application the way it was before you deleted a page. Export Preferences: This set of options is new in APEX 4.0 and allows for some additional control during the export process.

12


Figure 1-9. Exporting an application

An important consideration is whether you want developers to be able to access your application when it is imported to the target server. There is a trade-off between the added security you gain by exporting the application as Run Application Only versus not allowing your developers to access and debug the application via the Application Builder. When you set an application to Run Application Only, you lose the ability to debug (by changing the NO in the URL to YES) and trace that application (by adding p_trace=YES to the URL). Generally, you want to set your production applications to Run Application Only, so that end users can’t gain direct access to debug information that they shouldn’t be able to see.

Deploying Static Files APEX applications can include references to many different types of static files, including Cascading Style Sheets (CSS), images (JPG, GIF, and so on), JavaScript libraries, and Flash movies. You can reference these static files in two ways: •

They can be stored on a file system that’s accessible by the Oracle HTTP Server (OHS).

•

They can be uploaded to the database via the Application Builder interface.

Both methods have advantages and disadvantages, and you should be aware of how each method will affect your application. Whether you choose to store files in the file system or in the database

13


ultimately comes down to how you intend to manage those files and whether they need to be used by other external systems.

Uploading Static Files to the Database You can upload static files to the database simply by using a browser. This means that you can upload a new image to the database and use it in your application immediately, without needing to involve the person in charge of administering the web server. When you reference these static files in your application, they are actually downloaded to the end user’s browser via a database procedure. For example, if you uploaded a static file called logo.jpg, you could reference that file in an HTML region in your application with the following line of code: When that HTML region is processed, the #WORKSPACE_IMAGES# directive will be translated into something like this:

 Note In the example, the value used for p_security_group_id is modified so that it fits onto a single line on this book page. In reality, you would have a number such as 1635127392255802.

Any static files you reference in this way will be downloaded to the end user’s browser as a result of making a call to the get_file routine. This approach has two downsides: •

Each file you reference in this way requires a separate call to the get_file routine.

•

Quite often, browsers fail to store the image in their cache. In these cases, the static file will be rerequested every time the page is displayed, resulting in slowerloading pages and images that appear to flicker as they reload.

You can write your own get_file replacement procedure to enable the browser to cache the static files, as you’ll learn in Chapter 9.

Storing Static Files on the Server File System Storing files directly in the web server file system usually makes caching the static files happen transparently, since the OHS can add some default expiry headers to the file as it is requested by the user’s browser. When the user views the same page again, his browser determines whether the image can be reloaded from the browser cache or if it needs to be requested again from the web server. By taking advantage of caching for static files, your application will appear far more responsive to your end users, as well as put less load on your database. The downside of storing static files directly in the file system is that they aren’t as integrated with your application. For example, you’ll need to ensure that they are backed up as a separate process, since they won’t be backed up as part of the database. You also need to ensure that the file names on the file system correspond to the names you used to reference the files in your application.

14


Application Portability and Code Reuse APEX offers several features to make your application more portable between environments. We’ll look at a few of these features, as well as how to separate data and application logic from style and presentation.

Using Substitution Strings to Avoid Hard-Coding References Every application in APEX has a unique identifier—an application ID—assigned to it. This ID is used to identify the application and the associated metadata within the APEX repository. When you move applications between different APEX environments, such as between your development and test environments, you might encounter problems if you’ve hard-coded any references to values that may be different in these environments. Unless you can be absolutely certain that the application ID and any other references are exactly the same in the different environments, you shouldn’t hard-code any of these references. You can avoid hard-coding the application ID by using the APP_ID substitution string. Here’s an example of a typical URL where the application ID (112) has been hard-coded: f?p=112:1:&APP_SESSION.: If you import your application into an APEX environment that already has an application that uses the same application ID, forcing you to use a different ID, you may forget to update your hard-coded references. In that case, your links will point to the wrong application. To avoid this, you should use the APP_ID substitution string, which will be replaced with the actual ID of your application at runtime. Using this substitution string, the URL now looks like this: f?p=&APP_ID.:1:&APP_SESSION.: This makes your application more portable between APEX environments. Although it is not common for pages to be renumbered, you can also avoid having to hard-code a page ID by using the APP_PAGE_ID substitution string. This can be useful where you have a branch on a page that branches back to the same page. A page within an application can also have an alias defined for it. For example, you may give page 1 the alias of HOME, as shown in Figure 1-10. Now, rather than using a URL such as this: f?p=&APP_ID.:1:&APP_SESSION.: you can use this URL: f?p=&APP_ID.:HOME:&APP_SESSION.:

15


Figure 1-10. Defining an alias for the page By using the alias in the reference, you’ll be able to renumber the pages and the URL will still be pointing to the correct page. You should use substitution strings to avoid hard-coding any references to resources (such as style sheets) in templates and HTML regions. This will give you great flexibility to change the location of those resources, whether they are uploaded into the database or are stored in the file system. For example, if you stored all your images in the database by uploading them through the Application Builder interface, you might refer to a particular image file like this: At runtime, this will be expanded to reference the download procedure that is used for accessing static files that have been uploaded into the database. The text that is substituted at runtime will be something like this: wwv_flow_file_mgr.get_file?p_security_group_id=986113558690831&p_flow_id=112&p_fname =logo.gif In this section, I described #WORKSPACE_IMAGES# and #APP_IMAGES#. The simple difference between the two is that workspace images are available to any application in a workspace while application images are available only in the application to which they’re assigned. If you want to assign an image to an application, you specify the application name during the upload process. If you don’t specify an app name, the image will be available to all applications in the workspace. However, if you now wanted to store the images in the file system rather than in the database, you’d need to change every reference like this one to use a different path to the file. To simplify and minimize the number of changes you’ll need to make, you can define a substitution string that will be used in place of the #APP_IMAGES# substitution string. You can find the Substitution Strings section on the Application Definition page in the Shared Components part of the Application Builder, as shown in Figure 1-11. When you define the substitution string IMAGE_PATH for the value #APP_IMAGES#, the URL then looks like this:

16


Figure 1-11. Defining the alias to reference the #APP_IMAGES# substitution string Effectively, this creates a substitution string that references a substitution string. At runtime, this will be expanded to reference the same download procedure that was used before. The advantage of using this technique is that if you later decide to store the static files in the file system, rather than storing them within the database, you can simply change the value of your substitution string to reflect the new location, Figure 1-12 shows the substitution string modified to use a reference to the file system instead.

Figure 1-12. Changing the substitution string value to use the file system This greatly reduces the number of references you’ll need to change when moving your application between different APEX environments where the static files are stored in different locations, Figure 1-13 shows how the substitution string would be set in the development environment.

Figure 1-13. Substitution string set in the development environment

Using the Publish/Subscribe Feature The publish/subscribe feature allows you to reuse certain common components among applications. You can define your component in an application, and then other applications can reference that common component by subscribing to it. Any changes that are made to the master component can then easily be incorporated into the applications that subscribe to the component. Changes can be propagated from the master component to the subscribing component in two ways: From the master component: The master component publishes the changes to all subscribing applications. If you want the changes to the master component to be reflected in all subscribing components, you publish the changes from the master component.

17


From within applications: The subscribing applications refresh the components that subscribe to a master component. If you want only certain applications to have their subscribing components updated, you refresh the components from within those applications. The following components can make use of the publish/subscribe feature: •

Authentication schemes

•

Authorization schemes

•

Lists of values

•

Navigation bar entries

•

Shortcuts

•

Templates

When you create any of these component types, you have the option of subscribing to an already existing component of the same type. For example, suppose you create a master application that has a named List of Values (LOV) component that uses the following query: select ename d, empno r from

emp

order by 1 Figure 1-14 shows the results of using this LOV in a select list.

Figure 1-14. Using the master LOV in a select list

18


In another application within the same workspace, you can create a new LOV and choose to create it based on an existing LOV, as shown in Figure 1-15. The LOV creation wizard will then allow you to select which application (in the same workspace) should be used to list the available LOVs to subscribe to, as shown in Figure 1-16.

Figure 1-15. Creating an LOV that will subscribe to the master LOV

Figure 1-16. Copying the LOV from the master application Once you’ve selected an application, the LOVs available in that application will be displayed, as shown in Figure 1-17, allowing you to copy and subscribe to them.

Figure 1-17. Subscribing to the master LOV

19


If you now create a select list in the application that uses the LOV you’ve subscribed to, you will see the same list of employees displayed in the master application, as shown in Figure 1-18.

Figure 1-18. A select list based on the subscribing LOV If you decide you want to change the definition of the LOV so that the employees are listed in descending alphabetical order, you can go back to the master application and change the query as follows: select ename d, empno r from

emp

order by 1 desc At this point, the master application would display the employees in descending alphabetical order, while the application that subscribes to the LOV would still display the employees in ascending order. To update the subscribing LOV, you need to either publish the changes from the LOV in the master application, as shown in Figure 1-19, or refresh the LOV in the subscribing application, as shown in Figure 1-20.

Figure 1-19. Publishing the changes from the master LOV

20


Figure 1-20. Refreshing the subscribing LOV After you either publish the changes from the master application or refresh the subscribing LOV, the select list in the application will use exactly the same query that was defined in the master application. Figure 1-21 shows the select list now displaying the employees in descending alphabetical order.

Figure 1-21. Subscribing LOV refreshed with the master LOV The publish/subscribe functionality makes it far easier to maintain consistent appearance and behavior across common applications. You could create a single application that’s used as the master for all of your common applications, and then make changes to the common components in the master application and synchronize the changes to the other applications by publishing from the master application or refreshing from individual applications.

Separating Data and Application Logic from Style and Presentation To ensure that your applications and code are as portable and reusable as possible, you should strive to keep the data itself distinct from its presentation. This means that in general you shouldn’t embed HTML markup into the data-retrieval process. For example, suppose you want to display employee names in bold in a report. You could use a query like this: select '' || ename || '' as ename, deptno, sal from emp However, it’s better to keep the HTML markup out of the query. You could use a custom report template or use the column formatting section within the report attributes to apply some CSS formatting to the individual column. Then the query to bold the names would look like this: select ename, deptno, sal from emp Even in this simple example, it’s far easier to see at a glance exactly what this query is doing. You can also change the way the data is presented without needing to modify the query definition.

21


By keeping the HTML markup out of the query, you may find that your application performs better if you use the query in multiple places. Because the query is already stored in the shared pool, Oracle can take advantage of this by soft-parsing the query. If you embed the HTML markup in the query, Oracle will treat two queries as being different, even if only the embedded markup is different. For example, this query: select '' || ename || '' as ename, deptno, sal from emp would not be considered the same query as this one: select '' || ename || '' as ename, deptno, sal from emp If you run the first query and then the second query (for the first time), Oracle won’t find the second query in the shared pool. It would need to hard-parse the query, which would be more CPU-intensive than if it had found the query in the shared pool (and therefore could skip the hard-parse). Whenever you find yourself including HTML in a query, rethink your approach. Consider how you can use SQL features (such as DECODE, NVL, and so on) to add conditional logic to a report template to distinguish how different columns or rows should be displayed.

Using Page Zero If you want to display the same page element on all or multiple pages of your application, consider making use of page zero. When you place a page element on page zero, that element can be seen on all other pages of your application. By including some conditional display logic, you can restrict the element to appear only on certain pages. A common use for page zero is to include a navigational menu in an application. You can create a region on page zero that contains the menu, which then appears on every page. You can also include a region that contains a navigational menu for administrators. You would include a conditional display that shows this menu only if the application user is an administrator. By using page zero, you can centralize common components and functionality within your application. This also leads to a more consistent look and feel, since you can control the layout ofthe elements in a single place.

Performance Considerations You need to consider performance during the design and implementation of a system, rather than investigate it only after you’ve rolled out your application to the live environment (at which point it might be too late to correct any fundamental flaws in the design). Since the APEX environment runs entirely within the database, many of the recommendations for writing code and good schema design that perform and scale well are the same as for any PL/SQL programs or SQL queries. A sound understanding of SQL and PL/SQL is a definite benefit when developing with APEX. Take the time to learn about the latest features available in the database that might enable you to achieve your aims in a different way. For example learning how to use analytics might simplify many of your existing queries and make them perform better.

22


Bind Variables The importance of using bind variables in your code can’t be overstated. Bind variables not only help your code perform better, they also help protect you from SQL-injection attacks. For example, say we use the following piece of code to return the SQL that should be used in a report. The code checks whether the user has entered a value for the page item P1_SEARCH. If the page item is not null, the value is appended to the text that is returned. declare v_sql VARCHAR2(2000); begin v_sql := 'select name, salary from payroll where deptno = 10 '; if p_search is not null then v_sql := v_sql || 'and name=''' || p_search || ''''; end if; return v_sql; end; So, if the user entered SMITH into the search box, the following SQL would be returned: select deptno, name, salary from payroll where deptno = 10 and name = 'SMITH'; However, suppose a malicious user knows you have a function called delete_user with the following signature: function delete_user(p_id IN INTEGER) return integer That user could enter this into the search box: or delete_user(id) = 1 The query now looks like this: select id, deptno, name, salary from payroll where deptno = 10 and name = ' or delete_user(id) = 1' The seemingly innocent search becomes a mass employee-deletion routine. The proper way to handle this would be to not concatenate the user input directly to the SQL text: declare v_sql VARCHAR2(2000); begin if :P1_SEARCH is not null then v_sql := 'select name, salary from payroll where deptno = 10'; else v_sql := 'select name, salary from payroll ' || ' where deptno = 10 and name = :P1_SEARCH';

23


end if; return v_sql; end; Another potential danger in writing code that allows SQL injection is that a malicious user can add code like this: ‘or’1’=’1 As you can see, this code snippet can cause injected SQL to evaluate to true, potentially allowing users to access data they were not intended to see.

Report Pagination Style Different report pagination styles affect performance when displaying a report. For example, some pagination styles will display something like “Row Ranges X to Y of Z,” If you don’t need to display how many total rows are returned from the query, choose a pagination style that displaysonly “Row Ranges X to Y.” It is worth noting that if you decide to display the total number records the report will return, the database will fetch all the rows, even though you may not display them all. If you don’t need to display the total number of rows, the report will be rendered after the rows for the first page are fetched.

Error and Exception Handling Your APEX application can use many different anonymous PL/SQL blocks, functions, procedures, and packages as it executes. If an error or exception occurs during the execution of some code, you need to be able to handle that error or exception gracefully, in such a fashion that flow of execution by the APEX engine is not broken. For example, the following code catches an exception and sets the value of an application item: declare v_salary INTEGER; begin select salary into v_salary from emp where empno = :P1_EMPNO; return v_salary; :APP_ERROR_MSG := null; exception when no_data_found then

24


:APP_ERROR_MSG := 'Could not find the employee record.'; end; You can then display the application item on the page in an HTML region using this syntax: &APP_ERROR_MSG. You would then create a branch on the page to branch back to itself if the value of the application item is not null, thereby enabling the user to see the error and correct it.

Packaged Code APEX allows you to write SQL and PL/SQL codedirectly in a number of places via the Application Builder interface. For example, suppose you create the following after-submit process in your login page to audit that a user logged in to the application. begin insert into tbl_audit (id, user_name, action) values (seq_audit.nextval, :APP_USER, 'Logged On'); end; Now, while this would work, it means that if you ever want to modify the logic of the auditing, you need to change the application. For example, notice that you aren’t currently storing a timestamp of when the audit action was performed. To add that functionality, you’d need to modify the tbl_audit table and add an extra column to store the timestamp information (if that column didn’t already exist), and then edit the application to change the PL/SQL page process to include the timestamp information, like this: begin insert into tbl_audit (id, ts, user_name, action) values (seq_audit.nextval, sysdate, :APP_USER, 'Logged On'); end; So, for a very simple change, you might need to modify the application in development, export a new version of the application, import that version into a test environment, and so on through to production. A much more efficient approach is to try to isolate the number of places you directly code logic into your application by placing that code into a package and then calling the packaged procedure or function from your application. For example, you could change the PL/SQL page process to simply do this:

25


begin pkg_audit.audit_action('Logged On'); end; This allows you to encapsulate all of the logic in the packaged code. Assuming you aren’t making fundamental changes to the package signature, you can modify the internal logic without needing to change the application. This design allows you to change the table that the audit information is stored in or to add new columns and reference session state items without needing to change anything in the application itself. All you’d need to do is recompile the new package body in the development, test, or production environment. This would result in much less downtime for the application, since you no longer need to remove the old version of the application and import the new version. This method really does allow downtimes of just a few seconds (the time it takes to recompile the package body), as opposed to minutes, or potentially hours, while new versions of the applications are migrated. If you’re using the 11gR2 database, you can take advantage of edition-based redefinition, which allows for the creation of multiple versions of PL/SQL objects. Obviously, you won’t always be able to completely encapsulate your logic in packages. And sometimes, even if you do encapsulate the logic, you may need to change something in the application (for example, to pass a new parameter to the packaged code). However, it is good practice to use packaged logic where you can. Using packaged code can save you a lot of time later on, as well as encourage you to reuse code rather than potentially duplicating code throughout your application. Another benefit of using packaged code is security. The parsing schema can be granted execution privileges on the packaged code only, without having direct grants on the underlying objects. This obviates the need for at least two schemas, one to own the objects and another to act as the parsing schema. If the parsing schema is compromised, the underlying objects are still protected as only the packaged code is accessible via this schema.

Team Development The Team Development toolset is new in APEX 4.0. These tools enable management of the development process and tracking of new feature requests, bugs, and milestones. Before I delve into how these tools are used, it should be noted that Team Development does not perform source code control. That activity, sadly, is still handled as it was in previous versions of APEX and HTMLDB. What Team Development does provide is a centralized mechanism for recording requests and tracking the progress of development activities. The interface is straightforward but highly configurable, so some planning is required before putting these tools to full use. For businesses that use tools like Microsoft Project or Mercury Quality Center to track projects, Team Development may not be necessary. But for those without enterprise tools, these new features can be very beneficial—especially because they’re free.

Using Team Development To access the Team Development tools, simply log in to APEX as a developer. On the home page, you’ll see the Team Development icon as shown in as shown in Figure 1-22.

26


Figure 1-22. Team Development icon Once inside the Team Development system, you will see the types of project information that can be tracked. Figure 1-23 shows the Team Development dashboard. Before attempting to use these tools, a little planning is recommended.

Figure 1-23. Team Development dashboard

Preparing for Team Development To get the maximum benefit from the Team Development tools, it is important to understand the interrelationships among its five components. Features and milestones are the anchor components in a development project. Milestones are just what you’d think—a date that has some significance to the project. Once a milestone is defined, it can stand alone or be assigned to features, to dos, and bugs. Features are a little more complex since milestones, bugs, and to dos can be associated with a feature. In addition, one feature can be the parent of another. This allows for an endless hierarchy of features, which is why planning is important. You don’t want project management to be more complicated than the development process.

27


Figure 1-24 shows how you could build a hierarchy of features, bugs, to dos, and milestones with several parent-child relationships. Figure 1-25 shows a simplified method of managing a project. If you equate features to forms or reports, you can see that it’s easier to track features, bugs, to dos, and milestones using the simplified method. In any case, the Team Development tool offers managers and developers a centralized, web-based repository for storing bug reports, user requests, requirement changes, and so forth. This is a significant improvement over the traditional methods for recording this type of information: verbal conversations, handwritten notes, e-mail, etc. Since the Team Development interface is web-based, it can be used by anyone, whether APEX is being used for development or not.

Figure 1-24. Possible feature hierarchy

Figure 1-25. Recommended feature hierarchy

To enable Team Development for a project, the team lead should prepare by identifying the main functions of the application and recording them as features. Specific forms and reports are good candidates to record as features since users routinely report problems and request changes at these levels. In addition, if any milestones are known, they too can be recorded. From that point on, to dos and bugs should be recorded and associated to a feature or a milestone. As new features are added, they should be recorded as well. A simple workflow for setting up Team Development would include the following: 1.

Create features for all known forms, reports, etc.

2.

Assign any known to dos to their related features

3.

Assign dates to any known milestones

As the project progresses, new bugs and to dos can be assigned and the status of completed tasks can be updated.

28


Creating Features To create a feature, click on the Features icon on the Team Development dashboard and then click the Create button. Figure 1-26 shows the Feature entry screen. It is important to note that this form allows you to not only create a feature, but also to populate LOVs, which are used throughout the Team Development system. Fields used to build LOVs are: •

New Owner

•

New Contributor

•

New Focus Area

•

New Release

Because the data entered into these fields is accepted without validation, it can easily become polluted. Please note that the “Release” LOV is populated using this form. If Team Development is to be used effectively, data like Release numbers must be tightly controlled. For this reason, it is recommended that access to the Create Feature page be restricted to team leads.

Figure 1-26. Create Feature form The following LOVs are prepopulated at installation and can’t be changed via the Team Development interface: •

Feature Status

•

Desirability

•

Priority

29


While many of the fields on this form accept free-form text, Feature Status does not. It is used, as you will see later, to aid in project status reporting. The remaining attributes of this form are selfexplanatory and are common to most project management methodologies.

Recording Bugs and To Dos Once the testing process begins, your users will inevitably begin reporting bugs. The Bug form in the Team Development interface is used to record and manage this information. The Create Bug form, shown in Figure 1-27, is similar in functionality to the Create Feature form. As noted, bugs should be associated with features that equate to a form, report, etc.

Figure 1-27. Create Bug page

To dos are similar to bugs in that they are a record of some activity that needs to be done by some date. You could consider a to do as anything except a bug. Figure 1-28 shows the Create To Do page. Determining whether to use the Bug page or the To Do page is up to the team lead. As all developers know, testers often report bugs that may actually be requests for new or changed functionality. In such cases, the team lead may want to create a To Do so that the development team can address the issues appropriately. The main difference between these two objects is that the Bug page can record much more detailed information about the context of the issue. Like the Create Feature page, the Create Bug and To Do pages contain free-form text fields, LOVs, and fields used to populate LOVs. Using the recommended project management process, a bug or to do would be created and minimally assigned to a feature and to a developer.

30


Figure 1-28. Create To Do page

It is worth noting that to dos, like features, can be created in a hierarchical fashion. Although this is a powerful feature, it does allow complex hierarchies, which are difficult to track and manage. At least in the beginning, it is recommended that the depth of to do (or feature) hierarchies be kept to one or two levels.

Recording a Milestone A milestone is a significant date within a project plan. It can signify the required completion date of some unit of work, a business critical date like the end of a fiscal year, or something unrelated to the project like a public holiday. The Create Milestone page, shown in Figure 1-29, allows you to create a milestone, which can then be associated to a Feature, Bug, or To Do.

31


Figure 1-29. Create Milestone page

Once a milestone is set, it will show up on its assigned date on the project Calendar as shown in Figure 1-30. The annotation of the milestone (November 12 on the Calendar) is actually a hyperlink that, when clicked, causes the Edit Milestone page to be displayed.

Figure 1-30. Project Calendar Milestones can stand alone or can be assigned to any or all of the project’s features, bugs, or milestones. While this can be beneficial in managing a project, it does require the team lead to be diligent in determining how to associate milestones with other objects. It is important to note that any feature, bug, or to do can be assigned only one milestone at a time.

32


Gathering User Feedback New in APEX 4.0 is the ability to quickly create a page that lets users report system issues to the development team lead. While this may sound like a handy feature, I may recommend you avoid it for the following reasons: •

Nontechnical users sometimes have trouble describing system problems in a way that makes sense to developers

•

If you make it very easy to provide feedback, you’ll get lots of it. You will then have to spend time filtering out the “noise” in an effort to determine what is relevant and what is not.

I’ve been writing code and working with users for more than 20 years, and during that time I’ve followed one simple approach regarding user feedback: without meaning any disrespect, I don’t believe what anyone says about an application bug until I see it myself. When you are intimately familiar with a piece of code, no one can describe a bug in that code better than you. If at all possible, I recommend having a lead developer meet with the user community (or their reasonable facsimile) on a regular basis. The developer can then translate users’ concerns into actionable items for the development team. If you decide you want to include a Feedback page in your system, here’s is a brief description of how to do it: 1.

Add a page to an application, selecting “Feedback” as the type.

2.

Select “Yes” to add a Navigation Bar entry.

3.

Set the label for the Navigation Bar entry.

4.

Select “Yes” to Enable Feedback for this application.

Once you complete this process, your users can access the Feedback page from the Navigation Bar (next to the Login / Logout link). An example is shown in Figure 1-31.

Figure 1-31. Feedback page

33


One more time, though, beware of asking for unfiltered end-user feedback. You’ll get it.

Tracking Development Progress Without progress reporting, all the time and effort spent recording features, bugs, and to dos would be a waste of time. APEX 4.0 addresses this reality by providing mainly dashboards to track project activities. The dashboard for each type of work shows progress and status at a glance, but to get more detailed information, additional reports are available. The APEX 4.0 Team Development system does not contain a consolidated report that shows the status of objects across Features, Bugs, and To Dos, but does have a the Team Development home page that contains dashboards for all types of work. The main drawbacks to the Team Development system’s reporting capabilities are: •

Inconsistent status labels across Features, Bugs, and To Dos

•

No built-in report that consolidates Features, Bugs, and To Dos

Despite these drawbacks, it is still possible to effectively manage a project using the Team Development tools.

Feature Dashboard When accessing the Features dashboard from the Team Development home page, you’ll see a graphic that shows the percentage of Features that are complete and additional information on the total number of recorded features. This dashboard is unique in that a feature is considered complete when its status is set to “Functionally Complete – 80%” as opposed to 100% complete for a bug or a to do. The difference in status labels is a little annoying, especially since there is no way to set your own status labels via the Team Development interface. A feature (or a “page” in this example) that is marked “80% Functionally Complete ” is shown in Figure 1-32.

Figure 1-32. Feature dashboard

34


Bug Dashboard When you access the Bug dashboard from the Team Development home page, you’ll see a percentage graphic showing the number of “closed” bugs. A closed bug is one that has a status of “100.Complete.” If you have recorded 2 bugs and closed one, the Bug dashboard will show that 50 percent of the bugs are closed. Several additional links on the dashboard, as shown in Figure 1-33, can be used to navigate to the Bug details page.

Figure 1-33. Bug dashboard

To Dos Dashboard The To Dos dashboard is decidedly different from the Features and Bugs dashboards. While this page does show the completion status of all recorded To Dos as a percentage, it also contains a doughnutshaped graphic that shows the percentage of to dos assigned to each developer. If you have two developers and each is assigned one to do, the doughnut will be divided in half to show that each developer is responsible for 50% of the to dos. The graphic also acts as a hyperlink for navigating to a report of to dos by developer. Like bugs, to dos must be 100% complete before the dashboard will show a completion percentage. Figure 1-34 shows the To Do dashboard.

35


Figure 1-34. To Do dashboard Although it may be difficult to see in gray-scale, the doughnut-shaped graphic is divided in half and is shown in two distinct colors. Clicking either half of the graphic or any of the other hyperlinks on this page results in navigation to the associated to do detail page.

New Development Features in APEX 4.0 APEX 4.0 includes some interesting new features to assist in development and debugging. The APEX Advisor, for instance, is a utility that will scan your application (either completely or by specific page) and report on deviations from “APEX best practices.” You may or may not agree with what the Advisor says, but it makes finding certain type of errors much easier than digging through the code. For example, if you intend to include help on every field on all pages, the Advisor can quickly tell you whether you achieved your goal.

APEX Development Advisor You access the APEX Development Advisor from the Utilities menu of an application home page, as shown in Figure 1-35. You should review each of the Checks to Perform to ensure that you get only the information you need. In the Check Pages section, you can include a comma-separated list of page numbers to scan, or leave this area blank to scan all pages.

36


Figure 1-35. APEX Development Advisor The resulting “report” shows all of the areas that don’t meet the requirements of the Advisor. Using the example stated above (make sure all fields have help text defined), the Advisor was run on Page 1 of the Buglist application. The resulting APEX Development Advisor report shown in Figure 1-36 identifies a field as having no help text and includes a “View” link to take you directly to the item in question.

37


Figure 1-36. APEX Development Advisor report

APEX Code Debugger The integrated Code Debugger has a clean, graphical user interface to view detailed application execution details. Debugging can be enabled or disabled for an application using the Edit Application Properties button on the Application Home Page. Once debugging has been enabled, it can be activated at any time during execution (when running in development mode) by pressing the “Debug” button at the bottom of the application page. Clicking the “View Debug” button at the bottom of any page brings up the Debug Message page, as shown in Figure 1-37. This page displays a history of the debug sessions that have been run for this application and their relative time of execution.

Figure 1-37. APEX debug history

38


Clicking on the most recent debug session identifier opens another window showing the details of that session, as shown in Figure 1-38. The bar graph in the details window shows the execution times of each recorded activity. Hovering your mouse over the bars pops up some help text that describes the activity. Clicking on the bar will navigate to that activity in the debug details.

Figure 1-38. APEX Debugger

Summary This chapter covered some best practices for using APEX. You don’t need to follow our advice. Many people just charge in and begin coding without thinking to lay a solid foundation for their work. Some of what we advocate in this chapter may actually slow you down at first, but it will save you time in the long run. Helping you to work more efficiently, and taking a long-term view of doing that, is one of the reasons we’ve written this book. As for project management, we are discussing art as opposed to science. Each project manager has his own way of doing things so no single methodology works in every case. In instances where formal project management tools are not available, APEX 4.0’s Team Development tools can be a vast improvement over traditional methods that include e-mail, Excel, pencil and paper, and so forth. Hopefully, this chapter has exposed you to enough of the functionality that you can benefit from at least a portion of it.

39

CHAPTER 2 



Authentication and User Management Controlling who can and who can’t access your application is an extremely important consideration when designing your applications. The authentication method you choose for your application will define how the identity of users is determined and verified. A comprehensive security model will also address authorization—the process of specifying what a user can do once he is logged into an application. As you’ll learn in this chapter, APEX allows you to define many different authentication schemes in your application. However, only one of the schemes can be set as the current one. You can use one of the preconfigured authentication schemes or create your own from scratch, enabling you to build any logic you like into your authentication scheme. With APEX, you can specify, on a page-by-page basis, whether that particular page requires authentication or is public. If the page is public, anyone can directly access that page by typing its URL into a browser. Once users have successfully authenticated to your application, they will be able to access any pages in the application that require authentication without having to reauthenticate ( assuming the user passes any authorization checks, which we will cover in the next chapter). In other words, authentication is a one-time process—once you have authenticated, you remain authenticated for the duration of your session. Given increasing focus on application security, it is a common practice to time a session out after a period of inactivity. In earlier versions of APEX, you may have used custom functions to implement a session timeout, but this is no longer necessary in APEX 4.0. Both the session timeout (defaulted to 3600 seconds) and the maximum session length (defaulted to 28,800 seconds) can be set via the Security Settings section of the Manage Instance page.

Preconfigured Authentication Schemes APEX offers a number of built-in authentication schemes, including the following:

41

CHAPTER 2  AUTHENTICATION AND USER MANAGEMENT

Open door credentials: This scheme allows users to successfully authenticate using any username, without having to provide a password. The username is not checked against any sort of repository, so this scheme is really useful only for testing purposes or where you don’t need to enforce any form of account uniqueness. This scheme also allows you to simulate (in your development environment) what happens when you authenticate as a particular user in another environment (for example the production environment). No authentication: This scheme allows anyone to access the pages in your application, as long as the Oracle username and password specified in the database access descriptor (DAD) are correct. You will not be able to uniquely identify users in your application, since they will all be using the username specified in the DAD (for example, APEX_PUBLIC_USER or HTMLDB_PUBLIC_USER). Application Express account credentials: This scheme uses the built-in users and groups created by a workspace administrator within the workspace where the application is installed. This method is often referred to as cookie user accounts. It offers a quick way to manage and maintain a simple user repository without having to create your own user-management routines. Database account authentication: This scheme allows you to use Oracle accounts to authenticate your users against. Users need to specify a valid database username and password in order to successfully authenticate to your application. This scheme is ideal if you have already created a database user for each of your end users. Note that using database account authentication will not affect the parsing schema for your application. In other words, the authentication scheme uses only the username and password to authenticate with; it is not establishing a session to the database as that user, nor is it running any code as that particular user. LDAP directory: Using this scheme, you can authenticate users against any LDAP directory, which includes Oracle Internet Directory (OID), Microsoft Active Directory, and Sun iPlanet, among many others. Application server single sign-on: If you use Oracle Application Server, you can take advantage of single sign-on (SSO) against an OID LDAP server. Using SSO enables users to authenticate once against the SSO server, and then be able to access many different applications without needing to reauthenticate. To use a preconfigured authentication scheme, within your application in Application Builder, choose to create a new authentication scheme and select “Based on a preconfigured scheme from the gallery.” You will see the page shown in Figure 2-1.

42


Figure 2-1. APEX preconfigured authentication schemes You can view the existing authentication methods for your application by navigating to Shared ComponentsAuthentication Schemes. This takes you to a page that displays all of the authentication schemes defined for your application. The scheme that is currently being used is indicated with a check mark. Figure 2-2 shows an example of an application with the Application Express credentials and database account authentication methods defined, with Application Express credentials as the active method.

Figure 2-2. Authentication schemes defined for the application Rather than apply a preconfigured scheme, you can instead use a custom authentication scheme, which gives you complete control over how your authentication scheme works. Typically, you might write a routine that authenticates a username and password against details that have been stored in a table.

43


This chapter covers all the preconfigured authentication methods, except the LDAP directory and SSO authentication schemes, as well as creating custom authentication schemes.

Open Door Credentials With open door credentials, you are essentially declaring, “I want to allow anyone to authenticate to my application, just as long as they type in a username.” To use open door credentials, choose to create a new authentication scheme and select “Based on a preconfigured scheme from the gallery.” Then choose Show Built-In Login Page and Use Open Door Credentials (see Figure 2-1). When users run your application and try to connect to a page requiring authentication, they will be presented with a login screen similar to the one shown in Figure 2-3, where they will need to enter a username.

Figure 2-3. Open door credentials login screen Whatever the user enters as the username will be used as the APP_USER substitution variable. Since no password is requested and no validation is performed, users are free to use any username they like; for example, they could choose ADMIN or something else completely undesirable. Using the open door credentials authentication method is a good way to quickly test your application using different users without needing to maintain a user repository. This lets you track down problems that are perhaps related to the username (for example, authorization issues) without having that user in your user repository. Open door credentials authentication is rarely used outside development and testing environments. You will usually want to either make an application completely public (no authentication) or be able to differentiate among your individual users. Since the open door credentials method does not require a password, you won’t be able prevent different users from using the same username.

No Authentication It may seem strange in a chapter devoted to authentication to discuss no authentication. However, it is completely valid to have all of your pages accessible without requiring users to log in. To set up an application with no authentication, choose to create a new authentication method based on one from the gallery, and then select No Authentication (using DAD), as shown in Figure 2-1. Once you’ve chosen this scheme, users will be able to access the application without needing to authenticate. When you use the no-authentication method, the APP_USER substitution string that is used to identify the currently logged-in user will be set to the database user specified in the DAD configuration

44


file. Typically, the user in the DAD will be specified as HTMLDB_PUBLIC_USER or APEX_PUBLIC_USER, but it depends on your particular configuration. Since the DAD configuration file usually specifies both the username and password to connect to the database, the user will not need to authenticate. This authentication method is useful if you don’t need to protect your application in any way. If you want to allow anyone to view all the pages in your application, and you’re not concerned about the data they might be able to view and modify, this method is ideal. You may find it suitable when your application is essentially read-only—the end users just view the data (and that data is not deemed sensitive). You should also take into account that with the no-authentication method, any form of auditing you might be performing (for example, keeping track of records being deleted) will be of limited use. Every user will be identified as APEX_PUBLIC_USER or HTMLDB_PUBLIC_USER (as specified in your DAD), so you won’t be able to correlate the audit entries to a particular user.

Application Express Account Credentials Application Express account credentials, commonly referred to as cookie users or built-in users, is an authentication scheme that relies on a user repository within the APEX environment. Any user that is defined within the workspace in which the application is installed can be used to authenticate to the application. Using Application Express account credentials allows you to quickly and easily create and maintain users. The ease with which you can set up users makes this authentication scheme attractive for quick prototyping. One drawback to using Application Express account credentials is that users will be able to successfully authenticate to any application in the workspace that uses Application Express account credentials. However, you can use group membership and a custom authentication method to limit which users can successfully authenticate to your application. The following sections describe how to create users and groups, including how to use a custom authentication method to take group membership into account.

Creating New Application Users To create a new user who can authenticate to your application, log in to the workspace as a workspace administrator and navigate to Administration  Manage Application Express Users. From here, you can create a new end user for your application, as shown in Figure 2-4.

45


Figure 2-4. Creating a new end user Bear in mind that any end users you create will be able to authenticate to any application in that workspace that uses the Application Express account credentials authentication scheme. If you want to use this authentication method but would like to restrict the applications that users can log in to, you can use different workspaces to effectively partition your applications. Once users have been authenticated, some applications may display the logged-in username, depending on the theme used. For example, the Light Blue theme (theme 15) shows the current username in the top-right corner of the page, as shown in Figure 2-5. Other themes may display the username in a different position, and some themes may not display the username at all.

Figure 2-5. Username displayed in an application after a user has authenticated

46


 Tip If your application requires users to authenticate, displaying the username somewhere on the screen can be helpful. Being able to see the username at a glance can help to narrow down any problems you might have that affect one user but not another. Also, it’s a quick and simple visual cue for users, allowing them to see exactly which account they have logged in as.

Creating Groups As well as being able to create individual users with the Application Express account credentials authentication scheme, you can also create groups and then add individual users to particular groups. A group can contain more than one user, and a user can belong to multiple groups. To create a group, use the Manage Application Express Users link in the Application Builder. Figure 2-6 shows an example of a new group called End Users being created. After you create the group, you can make users members of that group. To do this, edit the individual user and select each group you want the user to be a member of, as shown in Figure 2-7.

Figure 2-6. Creating a new group

47


Figure 2-7. Adding a user to a group

Controlling Authentication with Groups As noted earlier, with groups, you can use a custom authentication method to limit which users can authenticate to your application. As shown in Figure 2-8, the default authentication function used for the Application Express account credentials method is the -BUILTIN- function. This method will automatically check the username and password being used against the cookie (or built-in) users for the workspace.

48


Figure 2-8. Using the -BUILTIN- authentication function In order to take group membership into account, you’ll need to replace the -BUILTIN- function with your own function, which should not only verify that the username and password are correct but also check that the user is in a particular group. To replace the existing -BUILTIN- authentication function with your own, you need to provide a function with the following signature: (p_username in varchar2, p_password in varchar2) return Boolean The function should take two parameters: one for the username and one for the password. It needs to return a Boolean value that indicates whether the authentication succeeded or failed. For example, Listing 2-1 shows a custom authentication function that allows any user to authenticate (we’ll get to a more useful function in a moment). Listing 2-1. A Simple Authentication Function That Always Succeeds create or replace function authenticate(p_username in varchar2, p_password in varchar2) return boolean is begin return true; end authenticate; You can then use your custom authentication function by replacing -BUILTIN- in the Authentication Function section of the Login Processing page with the following: return authenticate; This tells the APEX engine that it should call your authenticate function, passing in the username and password as parameters. The return result of your function is used to determine whether the user should be allowed to log in. It is extremely important that your function have the exact signature that is expected; otherwise, you may receive an error similar to this: ORA-06550: line 2, column 8: PLS-00306: wrong number or types of arguments in call to 'AUTHENTICATE' ORA-06550: line 2, column 1: PL/SQL: Statement ignored

49


The first step to making the authentication function useful is to modify it to verify the username and password in the same way that the -BUILTIN- method does. Fortunately, you don’t need to know the internals of where the usernames and passwords are stored, since APEX provides many helper packages, functions, and procedures to make your job easier. The apex_util package is one of these helper packages. It contains a number of functions and procedures directly related to working with cookie users. One such function is is_login_password_valid, which can be used to validate a username and password against the cookie users defined in the workspace in which the application resides. This function has the following signature: function is_login_password_valid(p_username in varchar2, p_password in varchar2) returns boolean

 Note The apex_util package was introduced in APEX version 2.2. If you have an earlier version, use htmldb_util or wwv_flow_user_api instead; for example, htmldb_util.is_login_password_valid.

As discussed in Chapter 1, it’s generally a good idea to put code such as a custom authentication method in a package, rather than using it as a stand-alone function. Using a package allows you to specify different authentication routines, perhaps one for development and another for a live environment. Then you can specify which authentication should be used in the package itself, rather than needing to modify the application when it is installed into the live environment. Listing 2-2 shows the new packaged function, which can be used as a direct replacement for the BUILTIN- method. Listing 2-2. Authentication Packaged Function create or replace package pkg_auth as function authenticate(p_username in varchar2, p_password in varchar2) return boolean; end; create or replace package body pkg_auth as function authenticate(p_username in varchar2, p_password in varchar2) return boolean is begin return apex_util.is_login_password_valid(p_username, p_password); end authenticate; end; You will also need to change the Authentication Function section of the Login Processing page so that it references the packaged function: return pkg_auth.authenticate;

50


Using this authentication function, any of the cookie users will be able to log in to the application, just as they could with the -BUILTIN- method. You now need to modify the function to take group membership into account. The apex_util package also contains a function called get_groups_user_belongs_to, which returns a string containing each group the user belongs to, delimited by commas. If the user doesn’t belong to any groups, the function actually returns NULL, rather than an empty string (which you might expect). The function also returns NULL if you query the groups for a user that does not exist. Listing 2-3 shows the updated packaged function that takes group membership into account. Listing 2-3. Authentication Package Function That Takes Group Membership into Account create or replace package pkg_auth as -- define a constant to represent the group name c_end_user constant varchar2(9) := ’end_users’; function authenticate(p_username in varchar2, p_password in varchar2) return boolean; end; create or replace package body pkg_auth as function authenticate(p_username in varchar2, p_password in varchar2) return boolean is v_groups varchar2(32767); v_arrgroups apex_application_global.vc_arr2; b_group_member boolean := false; b_login_correct boolean; begin -- check the username and password are correct b_login_correct := apex_util.is_login_password_valid(p_username, p_password); -- retrieve comma delimited string containing each group v_groups := apex_util.get_groups_user_belongs_to(p_username); -- convert the comma delimited string into an array v_arrgroups := apex_util.string_to_table( p_string => v_groups, p_separator => ','); -- loop round the array and compare each entry to the constant -- representing the group for i in 1 .. v_arrgroups.count loop if(v_arrgroups(i) = c_end_user) then b_group_member := true; end if; end loop;

51


return(b_login_correct and b_group_member); end authenticate; end; The package checks whether the username and password are valid, and whether the user is a member of the End Users group. In reality, you’d probably check one of these first, and then check the other only if the first condition evaluated to true. I wrote the example in this way so that it’s easier to see how the return result depends on both the b_login_correct value and the b_group_member value. You might think the package is more complicated than it needs to be, due to the use of the call to apex_util.string_to_table. You might be tempted to simply use INSTR or SUBSTR to determine whether the comma-delimited string contains the group name of interest. However, you’d need to be extremely careful about the group names you were searching for. For example, Listing 2-4 shows how a false match can be made, since the group being searched for (Admin) appears as a substring of another group that the user is a member of (Payroll Admin). Listing 2-4. Incorrectly Matching the Group Name Using an INSTR Match jes@10gR2> var mygroups varchar2(200); jes@10gR2> jes@10gR2> jes@10gR2> jes@10gR2> jes@10gR2> from dual

var check_group varchar2(200); exec :mygroups := 'Payroll Admin,End User'; exec :check_group := 'Admin'; col is_member format a10 select decode(instr(:mygroups, :check_group), 0, 'N', 'Y') is_member 

IS_MEMBER ---------Y Although this example shows how the INSTR function was used incorrectly, you don’t have to completely avoid it; APEX itself uses INSTR to parse the input string. To ensure that the :mygroups stringis parsed correctly, your decode must look for not only the group name, but also the delimiters. The code in Listing 2-5 shows the corrected decode statement. Listing 2-5. Correctly Matching the Group Name Using an INSTR Match jes@10gR2> select decode(instr(‘,’||:mygroups||’,’, ’,’||:check_group||’,’), 0, 'N', 'Y') is_member from dual

 Note The example in Listing 2-4 is not actually that contrived. In a very similar way, users of a production system (not an APEX system) were suddenly able to access parts of the system they should not have been able to reach. It was an absolute nightmare to track down the cause, mainly because developers swore that no code had been changed. Yet the application was behaving “incorrectly.”

52


Using the string_to_table routine to convert the comma-delimited string into an array makes searching through the entries much less error-prone when looking for an exact match. Whenever you write routines that deal with authentication and authorization, it’s important to consider how they could be abused. You need to check whether an end user could make the routine behave in a way you wouldn’t expect and possibly circumvent the security of your application, even unintentionally. It’s also a good idea to hand your routine to a colleague and ask her to “break this if you can.” It’s far better to have one of your colleagues find a security risk than have it discovered by an end user (or even worse, someone who shouldn’t even be an end user). The string_to_table routine is incredibly useful. The apex_util package also contains a table_to_string routine, which converts an array into a delimited string. These routines can save you a lot of time and effort when you need to pass multiple values around in your application. So, with the new packaged authentication function in place, you should find that you’ll be able to successfully authenticate to the application only if you enter a valid username and password, and the username you enter is a member of the End Users group. For example, the jes user will be able to log in, but the peterw user will receive the “Invalid Login Credentials” message. If you add the peterw user to the End Users group, then you’ll be able to successfully authenticate as peterw. You can now completely control which cookie users are able to successfully authenticate to your application. You can also deploy multiple applications within the same workspace and easily partition them from each other so that cookie users can’t access your application unless they are in a particular group. You can easily use this method to allow different users to authenticate depending on whether the application is running in the development, test, or live environment.

Maintaining Cookie Users Within Your Application Using the Application Express account credentials method is a very quick and easy way to establish a user repository for your application. However, many people don’t like having to connect to the workspace as a workspace administrator in order to create and maintain the users and groups. Once again, the apex_util package comes to the rescue—with routines that enable you to programmatically perform many of the tasks that you’d otherwise need to perform as a workspace administrator. For example, if you want to be able to create new users from within the application itself, you could use the apex_util.create_user function: procedure create_user and get the following results: argument name

type

in/out default?

--------------------------p_user_id p_user_name p_first_name p_last_name p_description p_email_address p_web_password p_web_password_format p_group_ids p_developer_privs p_default_schema p_allow_access_to_schemas

----------number varchar2 varchar2 varchar2 varchar2 varchar2 varchar2 varchar2 varchar2 varchar2 varchar2 varchar2

-----in in in in in in in in in in in in

-------default default default default default default default default default default

53


p_attribute_01 p_attribute_02 p_attribute_03 p_attribute_04 p_attribute_05 p_attribute_06 p_attribute_07 p_attribute_08 p_attribute_09

varchar2 varchar2 varchar2 varchar2 varchar2 varchar2 varchar2 varchar2 varchar2

in in in in in in in in in

default default default default default default default default default

p_attribute_10

varchar2

in

default

This function might look a bit overwhelming, but the majority of the parameters have default values. At the minimum, you could pass in just the p_user_name and the p_web_password parameters. For example, you could create a page process that contains the PL/SQL anonymous block code shown in Listing 2-5, passing in some of the page items as parameters. Listing 2-5. Calling the apex_util.create_user Function from a PL/SQL Page Process apex_util.create_user(p_user_name => :P1_USERNAME, p_email_address => :P1_EMAIL, p_first_name => :P1_FIRST_NAME, p_last_name => :P1_SURNAME, p_web_password => :P1_PASSWORD); Note that you can successfully call the apex_util.create_user function (and many of the other routines in the apex_util package) only if you are logged in to the application as a cookie user with workspace administrator privileges. If you attempt to execute the call while logged in to the application as a developer or end user, you will get an error similar to this: ORA-20001: User requires ADMIN privilege to perform this operation. Anytime you see this error on your page, it’s a sure sign you’re trying to call one of the apex_util routines while logged in to the application as a user who does not have ADMIN privileges. The apex_util package contains other useful routines for managing users, such as delete_user, create_user_group, and edit_user, as well as routines to get and set particular attributes, such as set_email_address. Using these routines, you can fully manage the cookie user repository from within your application. You could also use a separate administration application, which would enable you to present a more uniform appearance and seamless integration with your applications than you can with the workspace administration tools.

 Caution Many of the packages, functions, procedures, and views available in APEX work correctly only when they are used from within the APEX environment. For example, if you try to use them while connected to a SQL*Plus session, you may find that views return no rows and the functions and procedures don’t work, or they appear to work but don’t give the correct results.

54


The create_user function has attribute parameters, such as p_attribute_01, p_attribute_02, and so on, which you can use to store up to ten additional bits of information related to a particular user. For example, to store the telephone extension number for the user, modify the create_user call as shown in Listing 2-6. Listing 2-6. Using Custom Attributes in the apex_util.create_user Function apex_util.create_user(p_user_name => :P1_USERNAME, p_email_address => :P1_EMAIL p_first_name => :P1_FIRST_NAME, p_last_name => :P1_SURNAME, p_web_password => :P1_PASSWORD, p_attribute_01 => :P1_EXT_NUMBER); This example uses page items from page 1 in the application as the parameters to the procedure. For example, P1_FIRST_NAME is a page item where the user can enter a first name. You can then use the get_attribute function to retrieve the value for a particular attribute. For example, putting the following piece of code in a PL/SQL anonymous block region would display the value of the first attribute for the logged-in user: htp.p(apex_util.get_attribute(p_username => :APP_USER, p_attribute_number => 1)); Note that you refer to the attribute by number, not by name, so you need to be sure you’re consistent when you use the attributes. It’s easy to forget to change all references if you move the attributes around—for example, if you decide to store the extension number in p_attribute_02 rather than p_attribute_01. You can also store attributes with a user who has already been created by using the set_attribute function, as shown in Listing 2-7. One quirk of using set_attribute is that, rather than passing in the username as a string, you need to pass in the numeric ID of the username. (Not including an overridden set_attribute procedure that allows you to pass in the username as a string seems like an oversight, since many of the other administration routines in the apex_util package let you pass in either a string or numeric identifier.) Fortunately, you can easily retrieve this numeric ID for a particular username by using the get_user_id function, as shown in Listing 2-7. Listing 2-7. Using set_attribute to Store a User-Defined Attribute apex_util.set_attribute(p_userid => apex_util.get_user_id(:APP_USER), p_attribute_number => 1, p_attribute_value => :P1_EXT_NUMBER);

55


 Note The apex_util package contains many other useful procedures and functions. We encourage you to spend some time looking at its features. You can use it to build an extremely powerful and flexible user repository, which can be easily exported from one environment and imported into another.

Database Account Authentication Database account authentication was added in APEX version 2.2 (and is also available in the 2.1 release bundled with Oracle XE). This method allows you authenticate your users against real Oracle database accounts. To set up an application with database account credential authentication, choose to create a new authentication method based on one from the gallery, and then select Show Login Page and Use Database Account Credentials, as shown in Figure 2-9.

Figure 2-9. Creating an authentication scheme using database account credentials When you create the authentication scheme, you need to specify which login page you wish you use. You can usually select page 101 (assuming that’s specified as your existing login page), or you can use a built-in login page. You can change this option later by editing the authentication scheme, so it doesn’t really matter which you choose at this point. The disadvantage of using the built-in login page is that you can’t customize it as easily. When you use your own login page, you can modify it to make it more integrated with your application. Users will be able to successfully authenticate to your application only if they use a valid database username and password. This is an ideal solution if you are already using database accounts as a user repository for other applications. To allow a new user to authenticate to your application, you’ll need to create a new database user in the database. For example, you might create a demouser user while connected to the database with SQL*Plus:

56


system@10gR2> create user demouser identified by demopassword;

User created. You can now use this username and password to authenticate to the application, as shown in Figure 2-10.

Figure 2-10. Authenticated as the demouser database account The database authentication method obeys the rules regarding whether the account is locked. For example, the demouser account can be locked from a SQL*Plus session: system@10gR2> alter user demouser account lock;

User altered. If you then tried to authenticate as demouser user, you’d receive the message shown in Figure 2-11. The user will not be able to successfully authenticate to your application until the account is unlocked, as follows: system@10gR2> alter user demouser account unlock;

User altered.

57


Figure 2-11. Attempting to authenticate with a locked account At this point, you might start thinking of all the possibilities that have suddenly become open. For example, you might try to prevent an account from being shared by multiple people by restricting the number of times the user can be logged in simultaneously. This sort of functionality is relatively simple to achieve using Oracle accounts and profiles, as in this example: system@10gR2> grant create session to demouser; Grant succeeded. system@10gR2> create profile demo_profile limit sessions_per_user 1; Profile created. system@10gR2> alter user demouser profile demo_profile; User altered. Now if you were to use two different SQL*Plus sessions to connect to the database as demouser, the first connection would succeed, but the second SQL*Plus session would result in an error: Enter user-name: demouser Enter password: ERROR: ORA-02391: eceeded simultaneous SESSIONS_PER_USER limit The second SQL*Plus session will not be able to succeed until the first SQL*Plus session is ended. However, you’ll find that if you launch two separate browser sessions and try to log in to your application as the demouser in each session, both sessions will be allowed to successfully authenticate! The profile restriction you witnessed with a SQL*Plus session does not apply in your application. This demonstrates a very important point to remember when you use database authentication: •

58

Database account credentials are only used to authenticate against. You are not actually connecting to the database as that user. The connection to the database is made using the credentials specified in the DAD.


If you look closely at the example of setting up the restriction, you’ll see that it uses grant create session to demouser. This is necessary to log in to the account using SQL*Plus; otherwise, you would receive this error: ORA-01045: user DEMOUSER lacks CREATE SESSION privilege; logon denied However, you are able to authenticate to the application before that grant is performed. This clearly shows that database account authentication is not creating a session to the database as the username you logged in with.

Custom Authentication By creating your own custom authentication scheme, you are in complete control over how and where your user repository is stored and how you authenticate users against that repository. Your custom authentication scheme can be as simple or as complex as you need. You can create a custom authentication scheme that extends or adapts one of the preconfigured schemes in the gallery, or you can build an entirely new authentication scheme. One common custom authentication scheme can be referred to as “table-driven authentication.” With this type of scheme, you store your user repository in a table or across a number of tables. When a user tries to authenticate to your application, your authentication scheme checks to see if the supplied username and password match an entry stored in the table. The scheme can also include any other logic you’d like, such as checking to see if the account is active or inactive (similar to the locked/unlocked status for database account credentials). To demonstrate creating a custom authentication scheme, this section describes how to build a simple application using an Excel spreadsheet as the source. This application will be the basis for most of the examples in this and following chapters. Once the application is built, you’ll set up table-driven authentication. I’ll also cover some typical business requirements you might come across, including locking accounts and automating user registration.

Creating an Application from a Spreadsheet The previous version of this text went into greater detail on how to create applications using desktop tools as the source. While the ability to use desktop tools is a powerful feature, we will discuss it only as a method for creating a basic application, which we will then modify. Figure 2-12 shows the spreadsheet we’ll use to create the Buglist application. It is a basic spreadsheet with headings in row 1 and data in the subsequent rows. Apex will consume this file and create a report and a corresponding form for data entry and modification.

59


Figure 2-12. Bug Report spreadsheet To create an application from this spreadsheet, navigate to the Application Builder and click the Create button. Choose the option to create a Database Application and click next. The screen shown in Figure 2-13 allows you to specify that the new application will be based on a spreadsheet.

Figure 2-13. Create Application wizard

The spreadsheet wizard is very easy to use and creates a usable Apex application very quickly. In the next step of the process, you can either upload or cut and paste your spreadsheet into Apex as shown in Figure 2-14. If your spreadsheet is built such that you can use all of the contents, we recommend that

60


you upload the file. If you only want to use a portion of an existing spreadsheet, cutting and pasting is the way to go.

Figure 2-14. Preparing to upload a csv file or spreadsheet

To ensure that you get the data and only the data from the spreadsheet, the wizard asks for the field separator and for any delimiter that may be used to enclose strings of text. In most cases that use csv files, the field delimiter is the comma and the optional enclosing delimiter is the double quote mark. For the buglist file, the data is delimited by commas and there’s no optional enclosure, as shown in Figure 2-15.

 Caution Excel does not export CSV or tab-delimited data in UTF-8 by default. The data may become corrupted if you export from Excel using either of those formats and subsequently load that data into a UTF-8 database. If your database uses UTF-8, make sure to export from Excel in UTF-8.

61


Figure 2-15. Uploading a csv file or spreadsheet

Once the file has been uploaded, you can define the properties of the table that will contain the data from the spreadsheet. In this case, we called the table “BUGLIST” as shown in Figure 2-16. Since the column names from the spreadsheet are nice and neat, they don’t need to be changed. As you can see, you have complete control over the properties of each column in the source data.

Figure 2-16. Table Properties

62


Following the table definition, the Create Application wizard allows you to define the labels for each column on the data entry form as shown in Figure 2-17. The default values for column labels are the column names themselves. Since the column names are descriptive enough for a sample application, they can be left alone with the possible exception of “Bugid,” which could be changed to “Bug Id.” The singular and plural names are used on forms that we’ll develop later. You can use “Bug” and “Bugs” for now, but either can be changed later.

Figure 2-17. Setting user interface defaults

During the final steps of the creation process, you can assign the name, type, and visual attributes of the application. The available creation types are: •

Read Only

•

Read and Write; use this setting for the Buglist application

•

Report Implementation Type

Apex 4.0 provides two choices for Report Implementation: •

Interactive

•

Classic; use this report type

The “Classic” report contains standard text items and search buttons that can be easily manipulated using the standard features. The “Interactive” report type includes a Search field and a Go button, but they are not as accessible as the same values in a classic report. We will get into interactive reporting in later chapters.

63


You also set the theme, or look and feel, of the application at this point. For the Buglist application, I selected the light blue theme (theme 15).

Running the Application If you run the application you just created, you’ll be presented with a page asking for your username and password. This is because the application was created using APEX authentication, which means you’ll need to log in using the credentials of an APEX user created by a workspace administrator. Figure 2-18 shows the page that’s displayed once you have logged into the application.

Figure 2-18. Home page of Buglist application based on the spreadsheet.

Creating the User Repository For the custom authentication example, we will modify the Buglist application so that all of the user account information is stored in a table. At the very least, we want to be able to store the following pieces of information about a user: •

Username

•

Password

•

First name

•

Surname

•

E-mail address

Listing 2-8 shows the script for creating this user repository.

64


Listing 2-8. Script for Creating the User Repository apexdemo@10gR2> create table user_repository( username varchar2(8), password varchar2(8), forename varchar2(30), surname varchar2(30), email varchar2(50), primary key (username) ); Table created. apexdemo@10gR2> insert into user_repository values ('john', '1234', 'john', 'scott', '[email protected]'); 1 row created. apexdemo@10gR2> insert into user_repository values ('peterw', '9876', 'peter', 'ward', '[email protected]'); 1 row created. apexdemo@10gR2> commit; Listing 2-8 shows two records inserted into the table, representing two different user accounts. This table definition is relatively simple. We will extend this definition later to make it more realistic and useful. For example, Listing 2-8 uses plain-text passwords, which is obviously extremely bad practice. Later in the chapter, you’ll see how we can avoid using plain text and make the application much more secure. Notice that the username is specified as the primary key. This works because it’s unlikely you’d store two usernames with the same value. However, some people like to allow users to be able to change their usernames, and this approach would cause problems if the username were being used as a foreign key. For example, you might want to let a user who just got married change her username from anne_smith to anne_jones, but also want to maintain all of the user’s history. In that case, you might prefer to use a sequence as a surrogate primary key, rather than the username.

 Note Some people (such as the author) believe that entities such as usernames should be immutable. If the user wants to use a different username, you should create a new account with that new username, rather than letting the user change her username. The user can then stop using the old account and begin using the new one. Allowing identifiers such as usernames to be modified can create all sorts of headaches, particularly if you are trying to correlate audit log entries with a particular user. However, this is a personal preference. You may believe you have a valid business reason for allowing users to change their existing usernames.

65


Creating a New Authentication Scheme You can now create a new authentication scheme. When you create an authentication scheme from scratch, you can use the creation wizard to step through each setting, or you can create the scheme and then edit it later to make your configuration changes. Figure 2-19 shows a new authentication scheme being created.

Figure 2-19. Creating a custom authentication scheme from scratch You can define many attributes for a custom authentication scheme, so it’s worth taking the time to understand precisely what each attribute means: Page Sentry Function: You can specify a function that will be executed before a page in your application is requested or submitted. The function will return a Boolean value to indicate whether the page should be displayed or the user should be redirected to a login page, or some other page of your choice. If you don’t specify anything here, the built-in logic will be used.

66


Session Verify Function: The page sentry function will call this function to determine if a valid session exists for the current page request or submission. If you specified your own page sentry function, you don’t need to specify anything here, since your page sentry function should also perform the session verification. If you are using the built-in page sentry functionality, you can either specify your own session verification function here or leave it blank—in which case, the built-in functionality will be used. Invalid Session Target: You can specify the target that will be used if the page sentry function returns false, which indicates that the session is considered invalid. You can redirect the user to the built-in login page, a page in your application, a URL, or an Oracle SSO application server. Pre-Authentication Process: You can specify code that will be executed immediately before the user’s account credentials are verified. Authentication Function: This is where you can specify the function that will perform the credentials verification. The function you specify must accept two parameters: p_username and p_password, which are both of type VARCHAR2, and it must return a Boolean result, which is used to indicate whether the user has been successfully authenticated. Post-Authentication Process: This is similar to the preauthentication process, except it allows you to specify code that will be executed after the credentials have been verified. Cookie Attributes: This allows you to specify the cookie attributes for your application, such as the cookie name, path, and domain. Logout URL: This allows you to specify the value that will be used for the application attribute LOGOUT_URL, which is commonly displayed on the page for the user to click to log out of an application. You can include many substitution variables here, such as &APP_ID. (note the terminating period). For now, create the scheme by clicking Create Scheme. You can go back and change the individual items after you’ve created the function to perform the actual authentication. Your authentication function must have this signature: (p_username in varchar2, p_password in varchar2) return Boolean The function will need to compare the username and password with the rows stored in the user_repository table, returning true if the username and password match a row in the table, or returning false if no matching row can be found. Listing 2-9 shows the pkg_auth.authenticate function originally used in the Application Express Account Credentials section modified to verify users against the user_repository table.

67


Listing 2-9. The pkg_auth.authenticate Function Modified to Verify Users Against a Table create or replace package pkg_auth as function authenticate(p_username in varchar2, p_password in varchar2) return boolean; end; create or replace package body pkg_auth as function authenticate(p_username in varchar2, p_password in varchar2) return boolean is -- default the result to 0 v_result integer := 0; begin -- store 1 in v_result if a matching row -- can be found select 1 into v_result from user_repository where username = lower(p_username) and password = p_password; -- return true if a matching record was found return(v_result = 1); exception -- if no record was found then return false when no_data_found then return false; end authenticate; end; This authenticate function is straightforward. It simply tries to find a row in the user_repository table where the username and password match the parameters that were passed to the function. Notice that the p_username variable is being forced to lowercase. This is done for two reasons: 1.

The usernames inserted into the user_repository table are in lowercase

2.

The p_username variable will be passed in as uppercase from the application. Using lower() on the variable ensures that the cases in this comparison match. We avoid using a function on the username column as it may make an index on this column unusable.

Another way to handle this situation would be to populate the user_repository table with uppercased values. Since the application passes in uppercase values, the comparison would not require case conversion. You can verify that the packaged function works correctly by calling the function from some anonymous PL/SQL code in SQL*Plus, as shown in Listing 2-10.

68


Listing 2-10. Confirming the authenticate Function Works apexdemo@10gR2> set serveroutput on; apexdemo@10gR2> declare bres boolean := false; begin -- use the correct username and password bres := pkg_auth.authenticate('john', '1234'); if (bres = true) then dbms_output.put_line('Authentication was successful'); else dbms_output.put_line('Authentication failed'); end if; end; Authentication was successful PL/SQL procedure successfully completed. apexdemo@10gR2> declare bres boolean := false; begin -- use an incorrect password bres := pkg_auth.authenticate('john', '12345'); if (bres = true) then dbms_output.put_line('Authentication was successful'); else dbms_output.put_line('Authentication failed'); end if; end; Authentication failed

PL/SQL procedure successfully completed. You can now modify the authentication scheme to use the packaged function, as shown in Figure 2-20.

69


Figure 2-20. Using the packaged authentication function

 Note You could, if you prefer, remove the case-sensitivity match altogether to make it even more difficult for someone to guess usernames and passwords (in other words, not only does he need to guess the username, he also needs to know the exact case of the username). This means that JScott would be treated differently from jscott, for example. In general, though, you should not make usernames case-sensitive unless you have specific reason to do so. However, passwords should most definitely be case-sensitive.

Actually, you can use another method to completely remove the issue of the username being automatically uppercased. If you are using a login page that was generated for you automatically by the application creation wizard (as in the case of the Buglist application), there will be an after-submit page process on the login page called Login. If you examine this page process, you’ll find that it runs an anonymous PL/SQL block like this: wwv_flow_custom_auth_std.login( P_UNAME P_PASSWORD P_SESSION_ID P_FLOW_PAGE );

70

=> => => =>

:P101_USERNAME, :P101_PASSWORD, v('APP_SESSION'), :APP_ID||':1'


This piece of code will set the :APP_USER item and redirect to the value specified by the P_FLOW_PAGE parameter after a successful login. To prevent the username from being uppercased before it is passed to your authentication function, you can use the P_PRESERVE_CASE parameter to the wwv_flow_custom_auth_std.login function, as in this example: wwv_flow_custom_auth_std.login( P_UNAME P_PASSWORD P_SESSION_ID P_FLOW_PAGE

=> => => =>

:P101_USERNAME, :P101_PASSWORD, v('APP_SESSION'), :APP_ID||':1',

P_PRESERVE_CASE => TRUE );

Regarding Index Usage Although we’re not going to go into depthabout optimizing your queries, since that’s a topic that could easily span several books, it’s worth looking at the impact of modifying the query into one that performs a case-insensitive search against the username if you have a relatively large number of entries in the table. Suppose you insert an extra 9,999 rows into the user_repository table from a SQL*Plus session: apexdemo@10gR2> insert into user_repository (username, password) (select 'user' || rownum, 'pass' || rownum from all_objects  where rownum < 10000); 9999 rows created. apexdemo@10gR2> commit; The user repository now has more than 10,000 entries (including the 2 original ones). A user repository of this size is certainly not unusual for an Internet application or an intranet application of a large corporation. Make sure the statistics on the table are up-to-date: apexdemo@10gR2> exec dbms_stats.gather_table_stats('APEXDEMO', 'USER_REPOSITORY'); PL/SQL procedure successfully completed. Now if you view the explain plan for the original query, where the username is not uppercased: apexdemo@10gR2> select 1 as x from user_repository where username = 'john' and password = '1234' you’ll see something similar to this

71


X ---------1 Execution Plan ---------------------------------------------------------0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=18) 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'USER_REPOSITORY' (TABLE) (Cost=2 Card=1 Bytes=18) 2 1 INDEX (UNIQUE SCAN) OF 'SYS_C008389' (INDEX (UNIQUE)) (Cost=1 Card=1)

Statistics ---------------------------------------------------------1 recursive calls 0 db block gets 3 consistent gets 0 physical reads 0 redo size 386 bytes sent via SQL*Net to client 512 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1

rows processed

Notice this line: INDEX (UNIQUE SCAN) OF 'SYS_C008389' This shows that the query used the system-generated index that was created due to the primary key on the username column. Also, you can see that the query resulted in three consistent gets. Compare this with the explain plan you’d get for the query where you uppercase the username column: apexdemo@10gR2> select 1 as x from user_repository where upper(username) = 'JOHN' and password = '1234' X ---------1

72


Execution Plan ---------------------------------------------------------0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=9 Card=1 Bytes=18) 1 0 TABLE ACCESS (FULL) OF 'USER_REPOSITORY' (TABLE) (Cost=9 Card=1 Bytes=18)


rows processed

This time, the query results in a full scan of the user_repository table, because the upper function meant that the system-generated index could not be used. And as a result of the full scan, the consistent gets increase to 39. To avoid having to full-scan the table, you can create a function-based index, which will be used by the query that contains the function call on the column: apexdemo@10gR2> create index user_repository_upper_idx on user_repository(upper(username)); Index created. Note that the function uses the same function call that is used in the query. In other words, the function has been applied to the data for that column, and the result of the function call is then contained in the index, rather than the original data. If you now rerun the query containing the upper function call and look at the explain plan, you’d see something similar to this: apexdemo@10gR2> select 1 as x from user_repository 2 where upper(username) = 'JOHN' and password = '1234'; X ---------1

73


Execution Plan ---------------------------------------------------------0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=18) 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'USER_REPOSITORY' (TABLE) (Cost=2 Card=1 Bytes=18) 2

1

INDEX (RANGE SCAN) OF 'USER_REPOSITORY_UPPER_IDX' (INDEX ) (Cost=1 Card=40)


rows processed

You can see that the function-based index user_repository_upper_idx is now being used, and the number of consistent gets has dropped to 4. If you are not storing your usernames in uppercase in your table and you are making a call to the upper function in your query, investigate using a function-based index. You may feel that it’s not worthwhile if you don’t expect to have many users stored in your table repository. However, many huge systems have evolved from small ones, and quite often you don’t get the chance to check things until performance problems start to occur.

Hash Rather Than Crypt It’s a very bad idea to store a password in a table as plain text, since anyone who can access that table will be able to view the list of valid usernames and their corresponding passwords. As an alternative, you might decide to store the username in an encrypted format. While this is obviously more secure, it still poses a security risk. Encrypting the password implies that there is a decryption method. If your encryption method uses an encryption key, you’ll need to ensure that the key does not fall into the wrong hands; otherwise, the security can be easily compromised by running the encrypted value through the decryption routine using the key. A far better solution is to use a cryptographic hashing function such as MD5. A hash function will, for a given input, produce an output called the hash value. You can use this function to store the hash value, rather than the actual plain text password, in the table. The authentication function will then use the same hash function against the supplied password and produce a hash value that can be compared against the hash value stored in the user repository. Hash functions are one-way functions—you can’t obtain the original input value from the hash value.

74


Depending on the actual hash function, the chance of two inputs producing the same hash value can vary substantially. A hash value that can be produced by two different input values is known as a collision. If a function produces many collisions, malicious users would have an easier time gaining access, because they would only need to guess a password that produced the same hash value, rather than the precise password. The MD5 function produces very few collisions. In other words, it is mathematically unlikely that two input values will produce the same hash value. The dbms_obfuscation_toolkit package contains many procedures and functions related to encryption and hashing, including some for calculating MD5 hashes. Listing 2-11 shows how you can use the MD5 function call to convert a plain-text string into an MD5 hash value. Listing 2-11. Using the dbms_obfuscation_toolkit Package apexdemo@10gR2> var plaintext varchar2(30) apexdemo@10gR2> var hashvalue varchar2(32) apexdemo@10gR2> exec :plaintext := 'password'; PL/SQL procedure successfully completed. apexdemo@10gR2> exec :hashvalue := UTL_I18N.STRING_TO_RAW( dbms_obfuscation_toolkit.md5(input_string => :plaintext)); PL/SQL procedure successfully completed. apexdemo@10gR2> print hashvalue HASHVALUE -----------------5F4DCC3B5AA765D61D8327DEB882CF99 The dbms_obfuscation_toolkit package contains two overloaded MD5 functions. One accepts a RAW parameter and returns the result as a RAW. The other accepts a VARCHAR2 parameter and returns the result as a VARCHAR2. However, since the RAW data type is a subtype of the VARCHAR2 data type, this can lead to all sorts of problems when you try to call the MD5 function. Fortunately, the two functions have differently named parameters: FUNCTION MD5(INPUT IN RAW) RETURNS RAW(16)

FUNCTION MD5(INPUT_STRING IN VARCHAR2) RETURNS VARCHAR2(16) Listing 2-11 specifies the named parameter input_string so that the correct overloaded function will be used. Also, it uses the UTL_I18N package so that the string_to_raw function can be employed to cast the string returned from the MD5 function into the RAW format. This is a much friendlier hexadecimal format to read and store than the string, which would likely contain unprintable characters. You can now modify the user_repository table to add a column for storing the hashed password: apexdemo@10gR2> alter table user_repository add (password_hash raw(16)); Table altered.

75


Ideally, you’d update the table so that the password_hash column contains the MD5 hash of the password stored in the password column. However, if you try that, you’ll run into the overloaded function issue mentioned earlier: apexdemo@10gR2> update user_repository set password_hash = UTL_I18N.STRING_TO_RAW( dbms_obfuscation_toolkit.md5(password)); update user_repository set password_hash = UTL_I18N.STRING_TO_RAW( dbms_obfuscation_toolkit.md5(password)) * ERROR at line 1: ORA-06553: PLS-307: too many declarations of 'MD5' match this call You can’t use named parameters in SQL either, so it would be no good trying to specify input_string in the query: apexdemo@10gR2> update user_repository set password_hash = UTL_I18N.STRING_TO_RAW( dbms_obfuscation_toolkit.md5(input_string => password)) apexdemo@DBTEST> / update user_repository set password_hash = UTL_I18N.STRING_TO_RAW( dbms_obfuscation_toolkit.md5(input_string => password)) * ERROR at line 1: ORA-00907: missing right parenthesis Starting in 11g, you can use the utl_raw.cast_to_raw function instead of utl_i18n.string_to_raw and the following update statement will work: update user_repository set password_hash = UTL_raw.cast_TO_RAW(dbms_obfuscation_toolkit.md5(input_string => password )) To work around this problem in 10g versions of the database, you can create a function that will act as a wrapper around the MD5 call: apexdemo@10gR2> create or replace function md5hash (p_input in varchar2) return varchar2 is begin return upper(dbms_obfuscation_toolkit.md5 (input => utl_i18n.string_to_raw(p_input))); end md5hash; Function created. In 11g, the function would look like this:

76


apexdemo@10gR2> create or replace function md5hash (p_input in varchar2) return varchar2 is begin return utl_raw.cast_to_raw(dbms_obfuscation_toolkit.MD5(input_string=>p_input)); end md5hash; Although the dbms_obfuscation_toolkit package is still available in 11g (11.2.0.1), it is set to be deprecated. Its replacement is the dbms_crypto package, which you should start using instead of the dbms_obfuscation_toolkit. You can modify the md5hash function to use the new encryption package as follows: function md5hash (p_input in varchar2) return varchar2 is begin return dbms_crypto.hash(utl_raw.cast_to_raw(p_input),2); end md5hash; The dbms_crypto.hash function expects an input value of type raw and an encryption algorithm designator. The hash encryption types are as follows: 1 = MD4 2 = MD5 3 = SH1 To ensure that you get the same results from both the dbms_obfuscation_toolkit and the dbms_crypto packages, use the MD5 designator (2) in the call to dbms_crypto. apexdemo@10gR2> select md5hash('password') from dual; MD5HASH('PASSWORD') --------------------------------------------------------5F4DCC3B5AA765D61D8327DEB882CF99 You can now use this wrapper function to update the user_repository table: apexdemo@10gR2> update user_repository 2

set password_hash = md5hash(password);

2 rows updated. apexdemo@10gR2> commit; Commit complete. apexdemo@10gR2> select * from user_repository;

77


apexdemo@10gR2> select username, password, password_hash 2 from user_repository; USERNAME PASSWORD PASSWORD_HASH -------- -------- -------------------------------john 1234 81DC9BDB52D04DC20036DBD8313ED055 peterw

9876

912E79CD13C64069D91DA65D62FBB78C

You can make another improvement to this routine. The MD5 checksum is based only on the password, so two users who have the same password would have the same value in the password_hash column, as shown in Listing 2-12. Listing 2-12. Two Users with the Same Password Have the Same Password Hash apexdemo@10gR2> insert into user_repository  (username, password, forename, surname, email)  values ('jimb', '1234', 'James', 'Brookfield', '[email protected]') 1 row created. apexdemo@10gR2> update user_repository  set password_hash = md5hash(password); 3 rows updated. apexdemo@10gR2> select username, password, password_hash  from user_repository; USERNAME -------john peterw

PASSWORD -------1234 9876

PASSWORD_HASH -------------------------------81DC9BDB52D04DC20036DBD8313ED055 912E79CD13C64069D91DA65D62FBB78C

jimb

1234

81DC9BDB52D04DC20036DBD8313ED055

This sort of information could potentially be used as an attack vector if a malicious user discovered that he and another user had the same password hash value. Since the malicious user already knows his own password, he would be able to deduce the other user’s password from the fact that their hashes are the same. You can avoid this issue by passing in a string containing the concatenated username and password to the MD5 wrapper function, as shown in Listing 2-13. Listing 2-13. Combining the Username and Password in the Hash Function apexdemo@10gR2> update user_repository set password_hash = md5hash(upper(username) || password); 3 rows updated. apexdemo@10gR2> commit;

78


Commit complete. apexdemo@10gR2> select username, password, password_hash from user_repository; USERNAME -------john peterw

PASSWORD -------1234 9876

PASSWORD_HASH -------------------------------9B57B72DA06D24A934DEC92457B44974 F635746DF6E7E69D1B6698B79D65CD7F

jimb

1234

DF2270203A47F5A0A51D484D77C2FFC5

With this approach, even if two users have the same password, their hash values will be completely different. Note that you also uppercase the username before passing it to the MD5 hash function, since the username will uppercased before being passed to the custom authentication function, as described earlier. The authentication function can now be modified so that it performs the same hash function on the username and password the user is trying to authenticate with, and then compares that hash value with the hash value that is stored in the user_repository table, as shown in Listing 2-14. Listing 2-14. Modified pkg_auth Package to Work with Password Hashes Using dbms_crypto create or replace package pkg_auth as function authenticate(p_username in varchar2, p_password in varchar2)  return boolean; end; create or replace package body pkg_auth as -- wrapper function to compute the MD5 hash function md5hash (p_input in varchar2) return varchar2 is begin return dbms_crypto.hash(utl_raw.cast_to_raw(p_input),2); end md5hash; function authenticate(p_username in varchar2, p_password in varchar2) return boolean is v_result integer := 0; v_hash varchar2(32); begin v_hash := md5hash(p_username || p_password); select 1 into v_result from user_repository where upper(username) = upper(p_username) and password_hash = v_hash; return(v_result = 1); exception when no_data_found then return false;

79


end authenticate; end; Now you just need to remember to drop the plain-text password column from the user_repository table so that it can’t be viewed: apexdemo@10gR2> alter table user_repository drop(password);

Table altered. With a few relatively simple changes to the user_repository table and your authentication scheme, you have made your whole application much more secure. Also, by keeping the authentication code within a package, you are forming the basis of a security module that can be easily reused in different applications.

Implementing Locked User Accounts The ability to lock and unlock user accounts is very useful. For example, when employees leave a company, you probably don’t want them to be able to access your applications and systems. However, you may have problems deleting their accounts if their usernames (or other surrogate keys) are being used as foreign keys from other tables, such as an audit trail. An easier solution is to introduce an attribute into the account record that indicates whether it is locked. If an account is locked, the user can’t authenticate using that account. You can add an extra column to the user_repository table—a flag indicating the locked status. A value of Y indicates locked, and a value of N indicates that the account is not locked (and therefore the user is allowed to authenticate with it). Listing 2-15 shows the modifications. Listing 2-15. Adding the locked_flag and Constraint to the user_repository Table -- add the new columnn to the table apexdemo@10gR2> alter table user_repository 2 add(locked_flag char(1)); Table altered. -- set one record to be a locked status apexdemo@10gR2> update user_repository set locked_flag = 'Y' 2 where username = 'john';

80


1 row updated. -- set all the other records to unlocked apexdemo@10gR2> update user_repository set locked_flag = 'N' 2 where locked_flag is null; 2 rows updated. apexdemo@10gR2> commit; -- add a not null constraint to the column apexdemo@10gR2> alter table user_repository 2 modify locked_flag not null; Table altered. -- add a check constraint to ensure that the locked_flag is either 'Y' or 'N' apexdemo@10gR2> alter table user_repository add constraint 2 locked_flag_yn check (locked_flag in ('Y','N')); Table altered. apexdemo@10gR2> select username, locked_flag from user_repository; USERNAME -------david tim

LOCKED_FLAG --------------Y N

brian

N

You can now modify the authentication function to take the value in the locked_flag column into account when deciding whether to allow the user to authenticate. The simplest case would be to just include an additional where clause restriction in the query to search for a record where the username and password hash match and the account is not locked, like this: select 1 into v_result from user_repository where upper(username) = upper( p_username) and upper(password_hash) = v_hash ........................................ You will now find that if you attempt to authenticate to the application with a username that has the locked_flag set to 'Y' (or more correctly it isn’t set to 'N'), you won’t be able to log in. When you attempt to log in with a locked account, you’ll be presented with the “Invalid Login Credentials” message, as shown in Figure 2-21. Depending on your particular requirements, this may not be the most logical message to display.

81


Figure 2-21. Attempting to authenticate with a locked account This message appears because the page template for the login page includes the substitution item #NOTIFICATION_MESSAGE#. You might think it would be straightforward to change the message to something like “The Account Is Locked,” but that’s not the case. To understand why changing this message is not straightforward, you need to know what happens when a user tries to log in to the application.

Understanding the Login Process When a login page is created automatically by a wizard, it contains a page process with code similar to the following: wwv_flow_custom_auth_std.login( P_UNAME P_PASSWORD P_SESSION_ID P_FLOW_PAGE

=> => => =>


); The wwv_flow_custom_auth_std.login procedure is also known as the Login API. The Login API is responsible for performing the authentication and session registration for a user. It determines your current authentication scheme and interfaces with all of the authentication scheme items described earlier in this chapter (such as the authentication function). You can think of the Login API as a wrapper around the authentication scheme. The Login API produces the “Invalid Account Credentials” message if the authentication function returns false. There is no way to pass in an alternative message. The only way to change the message is by removing the call to wwv_flow_custom_auth_std.login and using your own logic to determine what should happen if the authentication fails. To help with this, you can use some of the built-in sessionhandling features. For example, you can replace the code in the login page process with the code in Listing 2-16.

82


Listing 2-16. Invoking a Custom Post-Login Procedure declare bresult boolean := FALSE; begin -- use the existing authenticate function bresult := pkg_auth.authenticate(upper(:P101_USERNAME), :P101_PASSWORD); -- call the post_login procedure if the -- authentication was successful if (bresult = true) then wwv_flow_custom_auth_std.post_login( P_UNAME P_PASSWORD P_SESSION_ID P_FLOW_PAGE ); end if;

=> => => =>


end; Here, you need to call the packaged authenticate function yourself. Since you are no longer using the Login API, the authentication scheme settings you’ve configured won’t automatically be used. Therefore, you need to replicate the implementation details of the authentication scheme. You call the post_login procedure if the authenticate function returns true (the authentication was successful). The post_login procedure’s signature is very similar to that of the login procedure; however, the post_login procedure is responsible for the session registration part of authentication. So unless you want to manually handle the session information yourself, it’s better to use the built-in methods. You should now find that you can still log in if you use a valid username and password (and the account is unlocked). However, if you use an invalid username or password or the account is locked, you are presented with a blank page. This is because you haven’t included any logic to specify what should happen if the authenticate function returns false. You can use two different ways to return users to the login page if their login was unsuccessful: •

Add a conditional branch to the page that fires when the Login button is clicked and branches back to login page. If the login is successful, this branch will not be executed. If the login is unsuccessful, this branch will fire and the user will be taken back to the login page.

•

Perform a redirect (using the owa_util.redirect_url procedure) back to the login page as part of the login page process logic.

Listing 2-17 shows the modified login page process, which now performs a redirect if the authentication was unsuccessful.

83


Listing 2-17. Performing a Redirect Back to the Login Page declare -- use the existing authenticate function bresult boolean := FALSE; begin bresult := pkg_auth.authenticate(upper(:P101_USERNAME), :P101_PASSWORD); -- call the post_login procedure if the -- authentication was successful if (bresult = true) then wwv_flow_custom_auth_std.post_login( P_UNAME => :P101_USERNAME, P_PASSWORD => :P101_PASSWORD, P_SESSION_ID => v('APP_SESSION'), P_FLOW_PAGE => :APP_ID||':1' ); else -- perform a redirect back to the login page owa_util.redirect_url('f?p=&APP_ID.:101:&SESSION.'); end if; end; Here, the login page ID is hard-coded (a bad practice!), to clearly illustrate which page is the target of the redirection. However, you could quite easily use a substitution item to avoid hard-coding the page ID.

 Note You could actually use the ID of any page that requires authentication, since the default behavior of trying to navigate to a protected page when you are not currently authenticated is to redirect you to the login page. However, for clarity, you should use the login page as the target for the redirection.

However, you don’t want to use page redirection for the redisplayed login page, because it could be treated as a completely new session (although sometimes the APEX engine is smart enough to detect that situation and issue the same session again). The correct way is to remove the redirection from the login page process and to use a page branch instead, as you’ll see in the next section.

84


Modifying the Notification Message Now that you’ve replaced the Login API with your own logic, you’ve gained full control over how the login process is handled. With this control, you can give users a meaningful error message if the account they try to authenticate with is locked. First, you create a new application item to use to store the message. You can then reference this application item in an HTML region on the page to display the message. Figure 2-22 shows the new LOGIN_MESSAGE application item. Notice that we set the session state protection to Restricted; we will cover this setting in more detail in Chapter 5.

Figure 2-22. Creating the LOGIN_MESSAGE application item The LOGIN_MESSAGE application item is then referenced in a new HTML region, as shown in Figure 223. This HTML region is positioned above the region containing the login page items, such as the username text field, so that the message will appear in a similar position to the notification message produced by the Login API. The region source simply uses the value of the application item, which is specified as &LOGIN_MESSAGE. (Note the trailing period.) Also, specify that no template should be used for the region.

85


Figure 2-23. HTML region referencing the LOGIN_MESSAGE application item Using the condition shown in Figure 2-24, this region will display only if the LOGIN_MESSAGE application item is not null; in other words, if a message has been set.

Figure 2-24. Conditional logic to show the region only if a message has been set Listing 2-18 shows the modified pkg_auth package body that will set the LOGIN_MESSAGE application item to a meaningful message. (Important changes are in bold.) Listing 2-18. Setting the Application Item from the pkg_auth.authenticate Function create or replace package body pkg_auth as function md5hash (p_input in varchar2) return varchar2 is begin return upper(dbms_obfuscation_toolkit.md5 (input => utl_i18n.string_to_raw(p_input))); end md5hash; function authenticate(p_username in varchar2, p_password in varchar2) return boolean is

86


v_locked_flag char(1); v_hash varchar2(32); begin v_hash := md5hash(p_username || p_password); select locked_flag into v_locked_flag from user_repository where upper(username) = upper( p_username) and upper(password_hash) = v_hash;

if v_locked_flag = 'N' then return true; else apex_util.set_session_state('LOGIN_MESSAGE', 'Your account is currently locked'); return false; end if; exception when no_data_found then apex_util.set_session_state('LOGIN_MESSAGE', 'Invalid username or password'); return false; end authenticate; end; As you can see, the query is modified so that if a record is found for that particular username and password, the value of the locked_flag is stored in the v_locked_flag variable. If the value of the locked flag is set to 'N' (meaning that the account is unlocked), the function returns true, allowing the user to successfully authenticate. If the value of the locked flag is not set to 'N', you use the apex_util.set_session_state procedure to set the value of the LOGIN_MESSAGE application item to 'Your account is currently locked'. If no matching account is found, the query will generate a no_data_found exception (due to the select...into... clause), and the no_data_found exception handler uses the apex_util.set_session_state procedure to set the application item to a meaningful message. The authenticate function then returns false (meaning the authentication was not successful) as before. Figure 2-25 shows the new logic for the login page process.

87


Figure 2-25. New login process logic You should also create a page branch that will branch back to the login page whenever the Login button is clicked, and an after-footer page process that clears the value for the LOGIN_MESSAGE application item. You need to clear the value so that the message is effectively reset each time the page is displayed; otherwise, the message would be displayed unnecessarily. After you’ve made these changes, you should find that users receive a meaningful error message if they use the incorrect credentials or if the account is locked, as shown in Figures 2-26 and 2-27.

Figure 2-26. Message the user receives after using incorrect credentials

88


Figure 2-27. Message the user receives if the account is locked Just to complete the example, you can replicate the way the original message looked when the login page process used the Login API. You can search through the HTML source for the page where the Login API is used to find where the “Invalid Login Credentials” message is displayed. You will find something like this: Invalid Login Credentials Depending on which theme you chose for your application, you may find that a different class is used. Change the region source for the HTML region used to display the message to the following: &LOGIN_MESSAGE. The message will now be formatted in the same way as if you used the Login API, as shown in Figure 2-28.

Figure 2-28. Using the original formatting of the notification message

A Note About Session Management In our example that modified the login page process, we used the standard wwv_flow_custom_auth_std.post_login procedure to complete the session registration once the user authenticated. By using the existing built-in session registration and session management functionality, we let the APEX engine take care of handling all of the details surrounding whether the user has a valid session, whether a new session needs to be established, and so on, which drastically reduced the amount of code we needed to provide in the authentication process logic.

89


In the vast majority of cases, you should take advantage of the built-in session registration and session management functionality by using the post_login procedure in your custom authentication processing. The Oracle developers behind APEX have put a lot of time and effort into making sure the built-in session-handling functionality works, and works well. It is tried-and-tested logic that is being used by many applications around the world. If you do feel you want to perform your own session-handling functionality, you should be prepared to do the following: •

Replicate the majority of the existing functionality and include your own custom handling.

•

Test your custom session handling ruthlessly to destruction and back again. Session-handling code is one area of your application that you really do not want to have bugs, since trying to recover from the aftermath of buggy session-handling code in a live environment is not for the faint-hearted.

 Note Applications that require their own custom session management routines are the exception rather than the norm. If you believe that your application requires custom session management, reconsider your business case to see if your requirements can be achieved in a different (and simpler) way.

Automating User Registration Many applications allow new users to register without manual intervention from an administrator. Typically, the registration process follows this series of steps: 1.

User enters details into a form, including e-mail address.

2.

An e-mail message is sent to the e-mail address provided. This message gives either a verification code that the user needs to enter on a web page, or contains a link the user should click to verify the account.

3.

Upon successful verification, the user will be able to authenticate to the application.

You can implement automatic user registration in the following ways: •

Create the user record directly in the user_repository table and use a flag to determine whether the account has been verified.

•

Create the user record in a holding table, and then insert it into the user_repository table once the user has responded to the verification e-mail.

Which method to use depends on your requirements. If you think a lot of people might indicate they want to register but then not respond to the verification e-mail, you may want to use a holding table. This avoids ending up with a lot of unverified records in the user_repository table, which could incur a performance penalty due to the need to search through more records when users try to authenticate. Or you may prefer to create the records directly in the user_repository table, so that you don’t need to go

90


through the process of copying the record from the holding table into the user_repository table and then deleting the original record from the holding table. Creating the records directly in the user_repository table has some other benefits. You can use a flag to indicate whether the account is verified. If you also record the timestamp of when the record was created, you can use a scheduled job to remove records that have not been verified within a certain period (for example, within 48 hours), so that you don’t end up with unverified accounts in your user repository. You could also take advantage of features such as table partitioning so that records that are verified are stored in one partition, while unverified accounts are stored in a different partition. This way, the query used in your authentication function will benefit from needing to look at only the records in the partition containing the verified records (unless you wanted to provide a meaningful “Your account is not verified” type of message). To demonstrate, let’s walk through the process of allowing user registration for the Buglist application. Although this functionality might not really be practical for this application, the same techniques apply to other applications.

Modifying the User Repository The first step is to modify the user_repository table to include a verified_flag column. Listing 2-19 shows the table being modified, as well as the current records being updated so that they are all in a verified status. Listing 2-19. Adding a Verified Flag to the user_repository Table -- add the new column apexdemo@10gR2> alter table user_repository 2 add(verified char(1)); Table altered. -- set one account to an unverified state apexdemo@10gR2> update user_repository set verified = 'N' where username = 'brian'; 1 row updated. apexdemo@10gR2> update user_repository set verified = 'Y' where username 'brian'; 2 rows updated. apexdemo@10gR2> commit; Commit complete. -- add a not null constraint to the new column apexdemo@10gR2> alter table user_repository 2 modify verified not null; Table altered. -- add a check constraint to the column

91


apexdemo@10gR2> alter table user_repository 2 add constraint verified_yn check (verified in ('Y','N')); Table altered.

Modifying the Authentication Method Now you need to modify the pkg_auth.authenticate routine slightly to take the verified flag into account, as shown in Listing 2-20. Listing 2-20. Modified pkg_auth to Handle Account Verification Status create or replace package body "pkg_auth" as function md5hash (p_input in varchar2) return varchar2 is begin return upper(dbms_obfuscation_toolkit.md5 (input => utl_i18n.string_to_raw(p_input))); end md5hash; function authenticate(p_username in varchar2, p_password in varchar2) return boolean is v_locked_flag char(1); v_verified char(1); v_hash varchar2(32); begin v_hash := md5hash(p_username || p_password); select locked_flag, verified into v_locked_flag, v_verified from user_repository where upper(username) =upper( p_username) and upper(password_hash) = v_hash; -- if the account is not verified then set the login message -- and fail authentication if v_verified = 'N' then apex_util.set_session_state('login_message', 'your account has not been verified yet'); return false; else if v_locked_flag = 'N' then return true;

92


else apex_util.set_session_state('login_message', 'your account is locked'); return false; end if; end if; exception when no_data_found then apex_util.set_session_state('login_message', 'invalid username or password'); return false; end authenticate; end; Now if you try to log in with an account that has not been verified (the verified column contains 'N'), you will receive the message shown in Figure 2-29.

Figure 2-29. Authentication message with an unverified account

Creating a Registration Form Next you need to create a simple registration form where users can enter their details. Figure 2-30 shows the form to capture the basic details to store in the user_repository table.

Figure 2-30. A simple user registration page

93


Adding a Verification Link Table Create an additional table to store the verification link that will be sent to the user, as shown in Listing 221. In theory, you could store the verification link in the user_repository table; however, since the verification link should be used only during the registration process, it seems unnecessary to clutter up the user_repository table with this data. Listing 2-21. Creating the verification_link Table apexdemo@10gR2> create table verification_link( 2 3 4 5

username varchar2(8) not null, registered timestamp, verification_code raw(16), primary key (username));

Table created. You’re storing the timestamp of when the user registered the account in the registered column. This column can be used within a cleanup routine that removes accounts over a certain age that haven’t been registered yet.

Adding a User Registration Procedure Add a register_user procedure to the pkg_auth package, as shown in Listing 2-22. This procedure inserts the user details into the user_repository table, and generates a verification link for that user and sends it via e-mail. Listing 2-22. User Registration Procedure procedure register_user(p_username in varchar2, p_password in varchar2, p_forename in varchar2, p_surname in varchar2, p_email in varchar2) is v_hash varchar2(32); v_code raw(32); begin -- generate the password hash for the user v_hash := md5hash(upper(p_username) || p_password); -- generate the verification link that will be used v_code := md5hash(p_username || dbms_random.string('A', insert into verification_link (username, registered,

94

8));


verification_code) values (p_username, sysdate, v_code); -- store the new account in the user_repository table -- the account is stored unlocked and unverified insert into user_repository (username, forename, surname, email, password_hash, locked_flag, verified) values (p_username, p_forename, p_surname, p_email, v_hash, 'N', 'N'); -- send the verification email send_verification_email(p_username, p_email, v_code); end register_user; This procedure uses the following code in generating the verification link: v_code := md5hash(p_username || dbms_random.string('A',

8));

The code uses the same md5hash helper function we used to generate an MD5 hash of the user’s password. However, in this case, you are using it to generate a verification link that is based on the username and a random string of characters (generated by using the dbms_random.string function). It’s perhaps easiest to visualize what the dbms_random.string function returns with an example: apexdemo@10gR2> select dbms_random.string('A', 8) as X from dual; X -------------------ZStZMclU apexdemo@10gR2> / X -------------------KBwWsrmj

95


apexdemo@10gR2> / X -------------------FQzCCTPI You concatenate the random string onto the end of the username before passing it to the md5hash function, just so the generated verification link is harder to deduce. This can be very important in an automated registration procedure where you want to prevent account generation from being abused by an automated tool written by a malicious user. Here we are going to modify the user registration page and add a PL/SQL page process, which calls the pkg_auth.register_user procedure, using the page items as the parameters when the user clicks the Register button. Note that you can modify the c_base_url variable to reflect the fully qualified URL the user should use. Although you could send a simple, single-line e-mail message from within the body of the register_user procedure, we’ll put the actual e-mailing of the verification link into a separate procedure so we can send a nicely formatted text e-mail message. You could even extend the example to send an HTML e-mail instead of a plain-text message, by using the P_BODY_HTML parameter to the APEX_MAIL procedure.

Adding the Procedure to Send the Verification Listing 2-23 shows the procedure for sending the verification e-mail message. Note that you’ll need to use the correct values for the address and port number of your own e-mail server in order to have the email sent. Listing 2-23. Procedure to Send Verification E-mail procedure send_verification_email(p_username in varchar2, p_email in varchar2, p_code in raw) is l_body clob; l_link clob; c_smtp_server varchar2(10) := 'localhost'; c_smtp_port integer := 25; c_base_url varchar2(200) := 'http://apexdemo/pls/apex/apexdemo.pkg_auth.verify_user?p_user='; c_from varchar2(30) := '[email protected]'; begin l_body := '==============================================' || utl_tcp.crlf; l_body := l_body || '= This Is an Automated Message, Do Not Reply =' || utl_tcp.crlf; l_body := l_body || '==============================================' || utl_tcp.crlf; l_body := l_body || utl_tcp.crlf; l_body := l_body || utl_tcp.crlf; l_body := l_body || 'Hello ' || p_username || ',' || utl_tcp.crlf;

96


l_body := l_body || utl_tcp.crlf; l_body := l_body || 'Thanks for taking the time to register.' || utl_tcp.crlf; l_body := l_body || utl_tcp.crlf; l_body := l_body || 'in order to complete your registration you will need to verify your email address.' || utl_tcp.crlf; l_body := l_body || utl_tcp.crlf; l_body := l_body || 'to verify your email address, simply click the link below, or copy it and paste it into the address field of your web browser.' || utl_tcp.crlf; l_body := l_body || utl_tcp.crlf; l_link := c_base_url || p_username || '&p_code=' || p_code; l_body := l_body || l_link || utl_tcp.crlf; l_body := l_body || utl_tcp.crlf; l_body := l_body || 'You only need to click this link once, and your account will be updated.' || utl_tcp.crlf; l_body := l_body || utl_tcp.crlf; l_body := l_body || 'You need to verify your email address within 5 days of receiving this mail.' || utl_tcp.crlf; apex_mail.send(p_to => p_email, p_from => c_from, p_body => l_body, p_subj => 'Your verification email'); apex_mail.push_queue(c_smtp_server, c_smtp_port); end send_verification_email; Notice that we call the apex_mail.push_queue procedure immediately after calling the apex_mail.send procedure. The send procedure just puts the mail into the APEX mail queue. Usually, a scheduled job will run every 10 or so minutes and push out all e-mail messages in the queue. Calling push_queue yourself sends the messages immediately, rather than waiting for the scheduled job. You can actually omit the hostname and port parameters from the apex_mail.push_queue procedure, since it picks up the server settings for those values (so you don’t need to know them yourself). You may wish to work with your e-mail server administrator to determine the best option for your system. Here’s an example of an e-mail message sent to a registering user. ============================================== = This Is an Automated Message, Do Not Reply = ============================================== Hello markw, Thanks for taking the time to register. In order to complete your registration you will need to verify your email address.

97


To verify your email address, simply click the link below, or copy it and paste it into the address field of your web browser (note this should be a single line, but is broken for clarity here). http://apexdemo/pls/apex/apexdemo.pkg_auth.verify_user ?p_user=markw&p_code=F6C61F52B08B5F9E5A684EFDD63D5709 You only need to click this link once, and your account will be updated. You need to verify your email address within 5 days of receiving this mail. Tying all these pieces together, you now have a process that does the following: •

Allows a user to submit their details into a page

•

Creates a new user in the user_repository table, with a status of unverified (verified is set to 'N')

•

Stores a record in the verification_link table that contains the username, when the account was registered, and the verification code

Handling the Verification Link The last ,step is to write the procedure that handles the verification link in the e-mail that the user will click. Listing 2-24 shows the definition of the pkg_auth.verify_user procedure. Listing 2-24. Procedure for Verifying Users procedure verify_user(p_user in varchar2, p_code in varchar2) is begin update user_repository ur set ur.verified = 'y' where upper(ur.username) = upper(p_user) and exists (select 1 from verification_link vl where vl.username = ur.username and vl.verification_code = p_code); if sql%rowcount > 0 then htp.p('Thank you, your account has now been verified.'); else htp.p('Sorry the link you have used is invalid.'); end if; end verify_user; Before this procedure can be called via a URL, you need to grant execute rights on it to the user specified in the DAD:

98


apexdemo@DBTEST> grant execute on pkg_auth to apex_public_user;

Grant succeeded. The user should now be able to click the link, and the verify_user procedure will try to match the username and the code used with the entry in the verification_link table. If a match is found, the corresponding user account in the user_repository table will have the verified flag set to 'Y'. Note the use of SQL%ROWCOUNT, so you can send a simple message back to the user’s browser to let the user know whether the verification succeeded. This simple example should give you some ideas about how you can set up an automated registration system. You could quite easily use this type of automated sign-up with some of the other authentication schemes. For example, with cookie user accounts, you could store the verified flag and the verification code using the custom attributes such as p_attribute_01, p_attribute_02, and so on. You could also make many improvements to this automated registration procedure,such as checking to see if the username is already registered.

Managing Session Timeouts In APEX 4.0, session timeout management is a built-in feature. You can set both a session-timeout value, which invalidates a session after some period of inactivity, and a maximum session-length value, which terminates an active session after a specified time period. To set these parameters, you must log in as an APEX administrator (using the http://…/apex/apex_admin URL). Both parameters are set in seconds via the Security screen under the Manage Instance menu as shown in Figure 2-31.

Figure 2-31. Entering session settings The values you set for the session timeouts should be based on either your corporate security guidelines (if they exist) or the usage patterns of your user base. If normal user operations include significant “think time” between transactions, you should set the Maximum Idle Time accordingly. You don’t want your users to have to re-login during a normal transaction. It is important to note that you can’t set an “unlimited” value for either parameter. The pop-up lists of values restrict entries to one of the following values: 1 Minute 5 Minutes 10 Minutes

99


30 Minutes 1 hour 2 Hours 5 Hours 10 Hours

Summary Authentication is important to any application because it’s the mechanism by which you ensure that users really are who they say they are. Authentication is a necessary precursor to authorization. You must first know who a user is before you can set appropriate limits on what that user can do. You can take advantage of several built-in authentication schemes that APEX provides, or build your own mechanism for authenticating users who log in to your applications. You can manage users individually, or you can place them into groups. Placing users into groups makes it more efficient to manage large numbers of users, because you define policies for a group at a time rather than one at a time. Chapter 3 builds on what you’ve just learned to demonstrate how to set limits on what users can do. Combining robust authentication with well-thought-out authorization ensures that application users can do only what they are supposed to be able to do—no more and no less.

100

CHAPTER 3

Conditions and Authorization Schemes This chapter covers two APEX features: conditions and authorization schemes. These two features can often be used to achieve the same thing: controlling the areas of your application the user can access and use. You can use conditions to control the rendering of page elements (such as regions, reports, and page items), as well as to control the execution of certain pieces of logic (such as processes and computations). Many application elements allow a condition to be applied to them. Authorization schemes similarly allow you to control the display and processing of elements within your application, but in a more secure manner. The key difference between conditions and authorization schemes is that a condition is used to control the rendering and processing of a specific element of your application (a page, a region, an item, and so on), whereas an authorization scheme is used to control access to a specific element in your application. The difference can be quite subtle, but as you’ll learn in this chapter, it’s also quite important.

Specifying Condition Types APEX offers many different condition types, and the number seems to increase with each new release. Figure 3-1 shows just a few of the condition types available. Each of these condition types is well-documented and -defined in the Oracle documentation. Here, you’ll see how to use some of the more common condition types in your applications, as well as some of the places you can use conditions to affect the elements that are displayed and processed on your page. We suggest that you refer to the Oracle documentation to review all of the condition types and experiment with them yourself. We also encourage you to check the list of available condition types whenever you upgrade to a new release of APEX to see if any new types have been introduced.

101

CHAPTER 3 ■ CONDITIONS AND AUTHORIZATION SCHEMES

Figure 3-1. Some of the condition types available in APEX As you will see, quite often, you can achieve the same result using different condition types. Your choice will depend on your particular situation and personal preferences. For example, although one condition type may perform better than another that achieves the same goal, if the condition isn’t evaluated that often, the performance aspect may not be as important as using a condition type that is easy to read. The key is to be aware of all of the different condition types available to you and how you can use them in your application.

No Condition The wording of the No Condition type varies depending on the actual element type you’re using. For example, it may read “Button NOT Conditional” if you are using a button, or simply “No Condition” for a report region. However, the result is the same: the page element will always be displayed. This is the default condition for newly created elements (unless you change it during the creation). It’s sometimes helpful to use the No Condition type during debugging to ensure that elements you wouldn’t normally see are working as intended.

Exists (SQL Query Returns at Least One Row) The Exists (SQL query returns at least one row) condition is perhaps among the first and most common condition types you’ll use. It allows you to easily tie the conditional display of an item to the existence of a record (or records) in the database. If you’re familiar with SQL, you’ve probably used this type of conditional SQL. For example, the Buglist application currently allows everyone to create new records, as shown in Figure 3-2. You can modify this behavior so that only certain users will be able to see the Create button.

102


Figure 3-2. Everyone is allowed to see the Create button in the Buglist application. Let’s say you want to show the Create button only to users who are designated as administrators. First, in the user_repository table, you need to identify which users are administrators. You can do that by adding a new column to hold an admin flag, as shown in Listing 3-1. Listing 3-1. Adding an admin Flag to the user_repository Table apexdemo@10gR2> desc user_repository; Name --------------------USERNAME FORENAME SURNAME EMAIL PASSWORD_HASH LOCKED_FLAG VERIFIED

Null? Type -------- ---------------NOT NULL VARCHAR2(8) VARCHAR2(30) VARCHAR2(30) VARCHAR2(50) RAW(16) NOT NULL CHAR(1) NOT NULL CHAR(1)

-- add the new column apexdemo@10gR2> alter table user_repository 2 add(admin char(1) default 'N'); Table altered.

103


-- modify the existing records so that 'toby' is an administrator apexdemo@10gR2> update user_repository 2 set admin = 'Y' where username = 'toby'; 1 row updated. apexdemo@10gR2> update user_repository 2 set admin = 'N' where username 'toby'; 3 rows updated. apexdemo@10gR2> commit; Commit complete. -- add a not null constraint to the new column apexdemo@10gR2> alter table user_repository 2 modify admin not null; Table altered. -- add a check constraint to the column apexdemo@10gR2> alter table user_repository 2 add constraint admin_yn check (admin in ('Y','N')); Table altered. Next, you need to check whether the user currently logged in to the application is an administrator, which will determine whether that user sees the Create button. In essence, you want to check whether a row exists in the user_repository table where the username is the same as the logged-in user and the admin flag is set to 'Y', as shown by the query in Listing 3-2. Listing 3-2. Query to Determine if the Current User Is an Administrator select 1 from user_repository where upper(username) = :APP_USER and admin = 'Y' You might wonder about the select 1 used in this query. You need to select something to return to the outer query, because the query is actually being used as an exists subquery. You could select the username or any other column or constant you preferred; however, doing a select 1 is a very common convention that you should follow, unless you have specific reasons not to use this convention. Also notice the uppercasing of the username, since the :APP_USER substitution variable will be in uppercase (as discussed in Chapter 2). You can now modify the condition type of the Create button to the Exists (SQL query returns at least one row) condition type and add the query, as shown in Figure 3-3.

104


Figure 3-3. Adding the Exists (SQL query returns at least one row) condition type to the Create button Now if you run the application while logged in as a nonadministrator, such as the brian user, you won’t see the Create button, as shown in Figure 3-4. If you log in as peterw, who is an administrator, you will see the Create button (as in Figure 3-2).

Figure 3-4. Nonadministrators no longer see the Create button.

 Caution At this point, you might be thinking that conditions are a great way of preventing people from doing things you don’t want them to do. Using conditions will stop page elements from being displayed or processed. However, knowledgeable users may still be able to get to a particular feature (such as the page to add a bug), even though you’ve used a condition to hide a button from them. In the “Authorization Schemes” section later in the chapter, you’ll see how users can circumvent conditional processing to reach areas of the application they shouldn’t be allowed to access. You should use authorization schemes (together with other techniques) to protect restricted areas of your application.

105


NOT Exists (SQL Query Returns No Rows) The NOT Exists (SQL query returns no rows) condition type, as you can guess from the name, is the inverse of the Exists (SQL query returns at least one row) condition type. In this case, if the query returns a single row (or more), the overall result of the condition is deemed to be false and the element will not be displayed or processed. In the previous example, we modified the application so that the Create button would appear only if the logged-in user was an administrator. This means that you can’t add any bugs until an administrator is defined. You could modify the logic so that if there are no administrators defined, everyone gets to see the Create button. In other words, you check the user_repository table to see if there are any records where the admin flag is set to 'Y' and the username is not the same as the current user. In a nutshell, what you’re asking is, “Is there another user who is an administrator?” To keep the example simple, we’ll assume that only one administrator is ever defined in the application. Listing 3-3 shows the new query logic. Listing 3-3. Query to Determine If Any Other User Is an Administrator select 1 from user_repository where upper(username) :APP_USER and admin = 'Y' You would modify the existing condition type to a NOT Exists type (you actually want to know if no other users are administrators) and put in the new query, as shown in Figure 3-5. If you now run the application and log in as the brian user, who is a not an administrator, the Create button will not be displayed, since the query will return a record for the peterw user, who is an administrator. And if you log in as the peterw user, you will see the Create button (since the query does not return any rows because there are no other administrators).

Figure 3-5. Adding the NOT Exists (SQL query returns no rows) condition type to the Create button To see the NOT Exists condition in action, update the user_repository so that no administrator is defined:

106


apexdemo@10gR2> update user_repository set admin = 'N'; 4 rows updated. apexdemo@10gR2> commit; Commit complete. Then when you log in as any user, you will see the Create button. Although the logic for this condition is probably not something you’d use in production, it does show that sometimes a NOT Exists condition may be a more logical choice than an Exists condition.

SQL Expression A SQL expression is essentially any Boolean expression that you might place into a where clause. In fact, the logic in SQL expressions is effectively evaluated as a where clause restriction in a SQL statement. In other words, the APEX engine will perform a query such as the following: select 1 from dual where where the condition evaluates to true if a row is returned from the query, and evaluates to false if no rows are returned. The earlier example of using an Exists condition type used the following piece of SQL (Listing 3-2): select 1 from user_repository where upper(username) = :APP_USER and admin = 'Y' The equivalent SQL expression logic would be something like this: :APP_USER in (select username from user_repository where admin ='Y') This would effectively become the following SQL statement: select 1 from dual where :APP_USER in (select upper(username) from user_repository where admin = 'Y') SQL Expression condition types can be useful when you simply want to write the logic of your condition in a shorter, more concise form than the full select statement (as you would with an Exists condition). For example, you could compare the current date in dd/mm/yyyy format against a page item P1_DATE with the following SQL expression: to_char(sysdate, 'dd/mm/yyyy') = :P1_DATE This is more readable than the slightly longer equivalent Exists condition:

107


select 1 from dual where to_char(sysdate, 'dd/mm/yyyy') = :P1_DATE Whether to use a SQL Expression condition type or an Exists condition type is often a matter of personal preference—whether you prefer to write out the entire query yourself or use the shortened form of a SQL expression.

PL/SQL Expression A PL/SQL Expression condition can consist of any valid PL/SQL syntax that evaluates to a true or false value. For example, you could use logic such as the following: length(:P1_USERNAME) < 8 This returns true if the value contained in the P1_USERNAME page item is less than eight characters long. Suppose that Buglist users must meet certain performance targets for the number of bugs they’ve successfully fixed and cleared each month. You can modify the application to display some text that reminds the users that they need to clear as many bugs as they can before the month ends. You want to display this message during the last week of every month. To do this, simply add a new HTML Text region to the page, as shown in Figure 3-6.

Figure 3-6. Creating the new Month End Reminder region

 Note This example uses the Sidebar Region template and positions the region in column 2. This means that it will display on the right side of the report on the page. Positioning and layout are covered in Chapter 5.

108


Since this is an HTML Text region, you can also include some HTML markup in the actual region source, as shown in Figure 3-7. Now if you run the application, you should see something like the screen shown in Figure 3-8. The reminder appears because it displays by default (remember that No Condition is the default).

Figure 3-7. HTML region source for the Month End Reminder region

Figure 3-8. Displaying the Month End Reminder region To determine the last week of the month, you can use some date and time functions available in Oracle, as shown in Listing 3-4. Listing 3-4. Determining the Last Week of the Month -- get today's date apexdemo@10gR2> select to_char(sysdate, 'dd/mm/yyyy') 2 as value from dual;

109


VALUE ---------11/18/2010 -- get the last day of the month apexdemo@10gR2> select to_char(last_day(sysdate), 'dd/mm/yyyy') 2 as value from dual; VALUE ---------11/30/2010 -- determine the current week number apexdemo@10gR2> select to_char(sysdate, 'w') 2 as value from dual; VALUE ---------3 -- determine the week number for the last day of the month apexdemo@10gR2> select to_char(last_day(sysdate), 'w') 2 as value from dual; VALUE ---------5 The method used in Listing 3-4 actually counts weeks in terms of days from the start of the month; that is, the first seven days in the start of the month are considered the first week, and then the next seven days are the second week, as opposed to running from Monday to Sunday. You can modify the Month End Reminder region to use a PL/SQL Expression condition that compares the current week number to the week number of the last day of the month, as shown in Figure 3-9. The region will now be shown only in the last seven days of the month.

Figure 3-9. Comparing the week numbers with a PL/SQL Expression condition

110


PL/SQL Function Body Returning a Boolean The PL/SQL Function Body Returning a Boolean condition type, as you’d guess, allows you to use a PL/SQL function that returns true or false to determine whether the condition succeeds or fails. For example, you could use something like the following code: begin if :APP_USER = 'BOB' then return true; else return false; end if; end; However, as discussed in Chapter 1, you should aim to put as much of your code as you can into packages, and to reference those packaged functions and procedures from your application. Therefore, rather than including the previous code in your application, you could put that code into a packaged function, then call that function in the condition: pkg_auth.check_for_bob; The advantage of using a package is threefold: •

It’s easy to reuse the code in another condition without having to copy and paste a lot of code.

•

If you want to change the actual logic of the condition, you can change it in only one place (the package), regardless of how many places you’re using it in your application.

•

You can change the logic in the package without needing to modify your application. You can modify and recompile the underlying package without having to recode anything in your application (since it is just calling the function).

Remember, it will be far easier to send a new package body to customers and tell them to recompile it than to give them an entire application—which they will need to upgrade—just because you want to change something in a single routine.

Request = Expression 1 Whenever a page is submitted, the value of the REQUEST application attribute is set to the name of the object that caused the page to be submitted. This happens, for example, when a user clicks a button or a particular tab. Using the REQUEST application attribute means you can perform different actions depending on what the user actually did. Now, let’s say you want to keep track of the search phrases people are using in the Buglist application. For example, you want to record that the user searched for the phrase “logo” as shown in Figure 3-10.

111


Figure 3-10. Searching for a particular phrase To accomplish this, first you need to create a table to store the search text, as shown in Listing 3-5. Listing 3-5. Creating the user_searches Table apexdemo@10gR2> create table user_searches(id number, 2 logged date not null, 3 username varchar2(8), 4 search_phrase varchar2(50), 5 primary key (id)); Table created. -- create a sequence to use as the PK of the table apexdemo@10gR2> create sequence search_seq cache 100; Sequence created. Next, you need to create a new PL/SQL page process that will fire after a page submission, as shown in Figure 3-11. The PL/SQL for the process will simply insert a record into the user_searches table: insert into user_searches (id, logged, username, search_phrase) values (search_seq.nextval, sysdate, :APP_USER, :P23_SUBJECT)

Figure 3-11. Creating a PL/SQL page process to store the user search

112


You also need to make sure that this process fires only if the user has clicked the Go button; otherwise, it will end up inserting rows into the user_searches table when the user performs other actions, such as navigating to the page using the Bugs tab. The key to doing this is to use the value of the REQUEST setting for the Go button, as shown in Figure 3-12.

Figure 3-12. Setting the REQUEST value associated with the Go button Often, with an automatically generated element, the REQUEST value will already be defaulted to something sensible. If not, you can set or change the value. It’s also very important to notice that you’re using the REQUEST value, not the name or label of the button. Many people get caught out by trying to use the label of the element rather than the REQUEST value, and then can’t figure out why their condition isn’t working the way they thought it should. With the REQUEST value of the Go button set to Go, you can use that value in the PL/SQL page process condition, as shown in Figure 3-13.

Figure 3-13. Using the Request = Expression 1 condition type to control the page process Now run the application and search for a particular phrase, such as “browser,” as shown in Figure 3-14.

113


Figure 3-14. Searching for the phrase “browser” Listing 3-6 shows that the search phrase, the username, and the timestamp of the search were all stored in the user_searches table. Listing 3-6. Querying the Entries in the user_searches Table apexdemo@10gR2> select * from user_searches; ID LOGGED USERNAME SEARCH_PHRASE ------- --------- -------- ------------------1 20-NOV-10 TIM browser Great, it all works. But you may have also spotted a problem with this way of recording searches. Currently, the PL/SQL page process will execute only if the user clicks the Go button. Many people simply press the Enter/Return key after they’ve entered something in the Search field. The existing logic won’t log those searches into the user_searches table. A simple way to address this problem is to make the REQUEST value of the Go button and the REQUEST value of the P1_REPORT_SEARCH text field the same. Then you’d need to check for only a single REQUEST value in the PL/SQL page process condition, regardless of whether the page was submitted as a result of the user clicking the Go button or hitting Enter/Return. However, if you examine the attributes of the P1_REPORT_SEARCH text field, you’ll see that, unlike for the button, you can’t specify your own REQUEST value for the text field. In the case of a text field (and other element types), the REQUEST value is defined to be the actual element name; that is, the REQUEST value for the P1_REPORT_SEARCH text item is P1_REPORT_SEARCH. Since you can’t change the REQUEST value of the text field to be the same as the button, you will need to change the REQUEST value of the button to be the same as the text field, as shown in Figure 3-15. You also need to modify the PL/SQL process condition so that it compares the REQUEST value against P1_REPORT_SEARCH rather than Go, as shown in Figure 3-16.

114


Figure 3-15. Setting the button REQUEST value to be the same as the text field

Figure 3-16. Using the shared REQUEST value in the PL/SQL page process All search queries will now be logged, regardless of whether the user clicks the Go button or presses the Enter/Return key.

Request != Expression 1 The Request != Expression 1 condition type is the reverse of the Request = Expression 1 type. This condition evaluates to true if the value of the REQUEST item does not match the value in Expression 1. The way to use this condition type should be fairly obvious from the example in the previous section.

Request Is Contained Within Expression 1 The Request Is Contained within Expression 1 condition type allows you to compare the REQUEST value against the multiple values specified in Expression 1. In the previous example that used the Request = Expression 1 condition, we modified the REQUEST value of the Go button to match the REQUEST value of the P23_SUBJECT text field so we could compare a single REQUEST value. Using the Request Is Contained within Expression 1 condition type instead, you

115


can simply use the two different REQUEST values, rather than needing to make the REQUEST values the same. If you change the REQUEST value of the Go button back to its original value of Go, you can modify the PL/SQL page process to use a condition like the one shown in Figure 3-17.

Figure 3-17. Using the Request Is Contained within Expression 1 condition type Notice that this example uses a comma-separated list of values in Expression 1. However, the text in Expression 1 is actually evaluated using an INSTR test, so the REQUEST value is tested like this: INSTR(text in expression 1, value of REQUEST item) > 0 and the condition is effectively evaluated as this: INSTR('P23_SUBJECT,Go', :REQUEST) > 0 So it does not really matter which delimiter you use. You could use a colon, an exclamation point, or any other symbol, since the values contained in Expression 1 are not being parsed into their individual values. Instead, the entire text in Expression 1 is searched to see if the string containing the REQUEST value appears anywhere within it. You need to be very careful when using Contained within Expression conditions, because of the opportunities for false-positive matches to be made. If you make poor choices for your REQUEST values, you may end up matching against a REQUEST value you didn’t intend to match against. As an example, imagine you have two buttons on your page: one used to submit the page, with a REQUEST value of Go, and another used to log the user out of the application, with a REQUEST value of Goodbye. Suppose you want to run a PL/SQL process when the user clicks the logout button, and therefore use the condition shown in Figure 3-18. The problem is that when the user clicks the submit button, which has a REQUEST value of Go, the APEX engine will perform this evaluation: if instr('Goodbye', 'Go') > 0 then return true; else return false; end if;

116


Figure 3-18. Using a bad choice of REQUEST value Because the letters Go appear in the text “Goodbye,” the condition will return true and the process will run, even though the user clicked the submit button rather than the logout button.

 Caution Check your REQUEST values to make sure that they will match only when you want them to, and try to avoid using a REQUEST value that is a substring of another REQUEST value. Note that you don’t need to worry about this issue when you use one of the condition types that deal with properly delimited values, such as those that are colon-delimited.

Value of Item in Expression 1 = Expression 2 The Value of Item in Expression 1 = Expression 2 condition type allows you to perform a case-sensitive comparison of the value of an item specified in Expression 1 with a string contained in Expression 2. For example, say you wanted to modify your application so that rather than logging every search phrase, it logs only the use of the search phrase “secure.” You can achieve this by modifying the conditional logic for the PL/SQL page process, as shown in Figure 3-19.

117


Figure 3-19. Comparing the value of the P1_REPORT_SEARCH item with a string Here you enter the name of the item P23_SUBJECT as Expression 1 and the text you wish to compare it with as Expression 2. Now an entry will be added to the user_searches table only if the user enters the word “secure” into the Search text field. Note that this performs an exact, case-sensitive match against the text in Expression 2. If the user enters “is it secure” or “Secure” in the Search text field, the condition will not evaluate to true and the search phrase will not be logged into the user_searches table.

Value of Item in Expression 1 Is NULL The purpose of the Value of Item in Expression 1 Is NULL condition type should be fairly obvious. This condition can be very useful. For example, you can easily modify your application so that users are given a warning if they click the Go button without entering a search phrase into the Search text field. Usually, the best way to achieve this is to use a validation, but you can implement similar functionality by creating a new field with warning text that will appear only if the Search text field is empty and the user clicked Go. Figure 3-20 shows the new text field.

Figure 3-20 Creating a new text field Set this text to display just to the right of the Go button by setting the Begin On New Line property to false as shown in Figure 3-21. Also change the template to Required, which will make the text appear in red. You can now check the value of the P23_SUBJECT item for a null value, as shown in Figure 3-22. Users will see the text warning if they click the Go button or hit the Return/Enter key without entering a search phrase, as shown in Figure 3-23.

118


Figure 3-21. Setting the display text to appear like a warning

Figure 3-22. Checking for a null search phrase

Figure 3-23. A warning message is displayed if no search phrase is entered. As mentioned, using a validation would be a far more sensible way of performing this check. However, sometimes methods like the one shown here can prove useful.

Current Page = Expression 1 The Current Page = Expression 1 condition is ideal when you use shared components or make use of page zero (covered in Chapter 1) and want to conditionally display or process a page element based on which page the user is currently viewing. For example, the Logout link is currently displayed in the top-right corner of the Buglist application screen. Suppose you want to make it visible only when the user is on the page containing the Bug report (page 1 in the application). To accomplish this, you can edit the navigation bar entry and use the condition shown in Figure 3-24. Now when the user clicks the Analyze tab, which will take him to page 5, the Logout link will no longer be visible, as shown in Figure 3-25.

119


Figure 3-24. Comparing the current page with an expression

Figure 3-25. The Logout link is no longer visible on any page other than page 1

Current Page Is Contained Within Expression 1 (Comma Delimited List of Pages) The Current Page Is Contained within Expression 1 (comma delimited list of pages) condition is similar to the Current Page = Expression 1 condition, but it allows you to supply a comma-delimited list of pages rather than just limiting you to a single page. For example, you could modify the previous example to display the Logout link for both pages 1 and 5, as shown in Figure 3-26. Using conditions like these, combined with features such as page zero, can lead to some incredibly sophisticated applications. They allow you to display page elements selectively on many different pages, without needing to add that page element to each individual page. Take advantage of this power to minimize the amount of manual work you need to do wherever you can.

120


Figure 3-26. The Logout link is no longer visible on pages 1 and 5

User Is Authenticated (Not Public) The User is Authenticated (not public) condition evaluates to true if the user has successfully authenticated to the application using the current authentication scheme, which can be either one of the built-in schemes or a custom authentication scheme. A typical use of this condition is to display different information to users depending on whether or not they are logged in to your application. For example, you might have a navigation menu that gives extra options to people after they have logged in. The previous example showed how to display the Logout link only if users are currently on page 1 or 5. A far more sensible usage would display the Logout link only if the user has actually logged in (is authenticated), as shown in Figure 3-27.

Figure 3-27. The Logout link is displayed only if the user is authenticated.

User Is the Public User (User Has Not Authenticated) The User is the Public User (user has not authenticated) condition is the reverse of the User is Authenticated (not public) type. It will evaluate to true if the user is not authenticated to the application. Here, Public User refers to whether the username is the same as the username that is specified in the DAD in your Apache configuration file, which is used to connect to the database. This username will typically be something like HTMLDB_PUBLIC_USER (if you have upgraded from an older version of APEX) or APEX_PUBLIC_USER; if you are using Oracle XE, it will typically be defined as ANONYMOUS. At the application level, you can set which value to use for Public User, as shown in Figure 3-28. Whenever the APP_USER variable equals the same value as you have specified at the application level, the user is deemed to be a public user.

121


Figure 3-28. Defining the Public User variable at the application level Figure 3-28 shows APEX_PUBLIC_USER specified as the Public User application attribute, which is the username specified in the DAD in this example. Until you log in to the application as another user, the APP_USER variable will be set to APEX_PUBLIC_USER (since that’s the username specified in the DAD). And until you successfully authenticate to the application, your current session will be classified as a Public User session. If you alter the Public User value to be something else (such as nobody), it will no longer match the username specified in the DAD, and so your unauthenticated session will not be classified as a Public User session.

Current Language Is Contained Within Expression 1 The Current Language is Contained within Expression 1 condition is extremely useful for enabling your application to take advantage of multiple-language support. Using this condition type, you can perform different processing depending on the language setting of the web browser that the user is using. For example, to detect whether the user’s browser is set to either French or German, you could use a condition such as the one shown in Figure 3-29.

Figure 3-29. Checking the browser language setting for French and German

122


In Chapter 11, you will learn how you can use this type of condition to build an application that uses the browser settings to determine the correct language translations and character set when displaying the pages. This lets you make your application accessible to a far wider audience.

Never As the name suggests, the Never condition will never be active—the page element will never be displayed or processed. You would typically use this condition type if you wished to temporarily disable a page element for debugging purposes. You might also use it to disable an element but not remove it completely from your application (in case you wanted to revert back to using it again in the future). However, leaving a lot of unused code lying around is generally not a good long-term strategy.

Using Conditions Appropriately Conditions can make it incredibly easy to dynamically modify the way your application behaves at runtime. However, sometimes it’s easy to misuse conditions to make your application behave in a particular way when another way of achieving the same result would be more appropriate. For example, suppose you want to modify your application so that only administrators are able to see the Submitted By and Assigned To columns in the report. You can define conditional display logic against individual columns in the report by selecting the column from the Report Attributes tab, as shown in Figure 3-30.

123


Figure 3-30. Selecting individual report columns You can use the same query we saw in the earlier example for determining whether the current user has the admin flag set to 'Y' (Listing 3-2). Figure 3-31 shows the conditional logic applied to the Submitted By column. After also applying the same condition to the Assigned To column, anyone who is not an administrator will no longer be able to view these columns, as shown in Figure 3-32.

Figure 3-31. Using an Exists (SQL query returns at least one row) condition to display an individual report column

124


Figure 3-32. Nonadministrators can no longer view the hidden columns. Using conditional display in this way is perfectly acceptable. In fact, it’s an extremely elegant way to dynamically change the way that the data is presented to different users (or different classes of user). Now suppose you also want to hide the Status and Priority fields from nonadministrators. You could easily do that by adding the same conditions you placed on the Submitted By and Assigned To columns to those two columns. In this case, you are now hiding four columns of data from the nonadministrators. However, the query is still selecting the data from those columns, regardless of whether or not the user is an administrator. This is where you need to use your judgment to determine whether applying conditions in this way is the best choice for your particular case. For example, if your application has 1 administrator and 99 nonadministrators, then (on average) you will be displaying all the fields that are being selected in the query only every 1 in a 100 times. In other words, the vast majority of the time you are having the query select columns you are not actually going to use—making the database perform extra, unnecessary work. It’s very important to realize that when you place conditions on report columns, you are not modifying the actual query that is being performed. You are affecting only which columns will be displayed after the query has been performed.

125


To achieve the same end result, you could have two different report regions: one with the query to select the columns that administrators should be able to see, and the other whose query selects the columns that nonadministrators should be able to see. You would then use mutually exclusive conditions so that only one report region was shown at a time—if the user is an administrator, the report region relevant to administrators is processed and vice versa. However, duplicating the report region in this way adds extra overhead in terms of maintenance for your application, meaning that if you wanted to change something, you might need to change it in two places rather than just one place. Perhaps a better alternative would be to change the report region type from SQL Query to SQL Query (PL/SQL function body returning SQL query). This would allow you to use a PL/SQL function to return a different SQL query for the report to use depending on whether the user was an administrator. Don’t be afraid to reevaluate your options when the requirements change. You may find that the method that used to suit your needs perfectly has now become less attractive.

Authorization Schemes Like conditions, authorization schemes allow you to control the display and processing of elements within your application. However, unlike a condition, an authorization scheme is a far more secure choice when it comes to restricting the areas of your application that a user should be able to access. An authorization scheme is similar to an authentication scheme and condition type in that it is a piece of logic that returns a true or false value. If it returns true, the authorization is deemed to have been successful; otherwise, the authorization fails. You can create new authorization schemes for your application from the Shared Components section of the application builder, as shown in Figure 3-33. Any existing authorization schemes can also be accessed from here.

Figure 3-33. The Authorization Schemes page

Creating an Authorization Scheme The difference between a condition and an authorization scheme starts with the way in which you define the two. Whereas the logic for a condition is defined for a particular element (for example, a page item or a region), an authorization scheme is defined in one place and is then available to be used by one or more of your application elements. As an example, we will create an authorization scheme that determines whether the current user is an administrator. First, you need to create the scheme itself. The wizard gives you the choice of whether you wish to create a scheme from scratch or to base the scheme on an existing schema, as shown in Figure 3-34.

126


Figure 3-34. Creating a new authorization scheme As when you define the logic for a condition, you can select from different authorization scheme types, such as Exists SQL Query and PL/SQL Function Returning a Boolean. The list of types is nowhere near as comprehensive as the list of condition types, but it is usually sufficient to cover the vast majority of authorization schemes you might want to create. As shown in Figure 3-35, name the new scheme USER_IS_ADMIN and choose the Exists SQL Query scheme type. For Expression 1, use the same query as the one you used earlier (Listing 3-2) for the Exists (SQL query returns at least one row) condition. You must also specify an error message that will be displayed to a user when the authorization scheme fails. Supplying an error message is mandatory for an authorization scheme, unlike with a condition.

127


Figure 3-35. Defining the authorization scheme logic An important configuration setting you can define for an authorization scheme is called the evaluation point, as shown in Figure 3-36. You can use the evaluation point setting to define whether the authorization scheme logic should be evaluated every time you view a page that uses it or evaluated only once per session. For this example, choose once per session.

Figure 3-36. Defining an evaluation point When you choose once per session for the evaluation point, the result of the authorization scheme is cached, and the cached value is used whenever an element references the authorization scheme. If the logic in your scheme is particularly time-consuming and the results probably won’t change that often, taking advantage of the caching facility will lead to a much more responsive application for the user. For example, if the logic takes one second to perform and you use that authorization scheme on a lot of

128


different pages, the user won’t need to wait that extra second per page (and shaving a second off your page-delivery times can make a big difference to the users’ perception of your application). We’ll discuss the evaluation point choice in more detail in the “To Cache or Not to Cache” section later in this chapter. Next, return to the Home page in your application and ensure that the condition type for the Create Bug link is set to No Condition Specified, as shown in Figure 3-37. As mentioned earlier, this is a quick way of disabling the condition without needing to remove the code. Then use the Authorization Scheme drop-down list, shown in Figure 3-38, to select the USER_IS_ADMIN scheme you created.

Figure 3-37. Defining the authorization scheme logic

Figure 3-38. Selecting one of the available authorization schemes As you can see, three schemes are available, even though you created only one: Must Not Be Public User: This scheme is added automatically. As the name suggests, it is a good way to determine if the user is authenticated to the application. This scheme uses the value of the Public User application attribute that was discussed earlier in the section about the User is the Public User (user has not authenticated) condition type. USER_IS_ADMIN. This is the scheme you added using the wizard. Not USER_IS_ADMIN. This scheme is also added automatically. It is the reverse of the scheme you just created. Whenever you create a new scheme, APEX will automatically create the reverse of the scheme for you. This makes it very easy to not only check that the user is an administrator, but also that the user is not an administrator. Now the Create link should behave as it did before, appearing only to people who are administrators. One big difference between using conditions and using authorization schemes is that you can easily reuse an authorization scheme with other page elements simply by selecting it from the drop-down list.

129


Any changes to the authorization scheme will automatically be reflected in any elements that use the scheme.

Protecting Your Resources At first glance, it might look like you have succeeded in preventing nonadministrators from being able to create new records, since they can no longer access the Create button. However, it’s important to note the distinction here between the following: •

Preventing the user from seeing the button

•

Preventing the user from doing whatever clicking the button would have done

When users click the Create button, they are redirected to page 2 of the application, as shown in Figure 3-39, which is the page where they can create a new record. Also notice in Figure 3-40 that the cache is cleared for page 2. Any page items that are defined on page 2 will have their session state cleared, since you’d usually want the page to default to blank entries when you are creating a new record.

Figure 3-39. The Create button redirects the user to page 2 in the application. So, what would happen if a nonadministrator tried to get to page 2 by typing that address into a browser? Well, that’s easy to test. Simply change the page number specified in the URL of the browser to go to page 2 instead of page 1. In the browser, the URL will contain something like this: http://127.0.0.1:7780/pls/apex/f?p=101:1:2357672961634263 where 101 is the application ID, and 1 is the page number. The long number after the page number is the session ID. Modify this URL as follows: http://127.0.0.1:7780/pls/apex/f?p=101:2:2357672961634263

130


and then press the Enter/Return key to submit the URL request to the browser. You will see that a nonadministrator user can still access the page for creating new records, as shown in Figure 3-40.

Figure 3-40. A nonadministrator is still able to access a page he should not be able to view. This is where the simplicity and power of authorization schemes become very useful. You can apply the same USER_IS_ADMIN scheme to an entire page. To do so, edit page 2 of the application and go to the security settings, as shown in Figure 3-41.

Figure 3-41. Setting the authorization scheme for the entire page Note that the authorization scheme can work independently from any authentication settings you have made for the page. Here, you are not only saying that users need to be authenticated to view this page, but they also need to pass your authorization scheme check, and therefore they must be an administrator. If you now repeat your test and modify the URL for a nonadministrator to navigate directly to page 2, you will see the error message shown in Figure 3-42.

131


Figure 3-42. Your error message appears when a nonadministrator tries to access a page protected by an authorization scheme. To properly protect the resources in your application, make sure that when you are restricting the display of certain page elements, you also protect the resources for which those page elements are responsible. It’s not enough to just hide all the links and buttons to a particular page, for example. Make sure you protect access to that page itself with an appropriate authorization scheme. This applies equally to any processes your pages might execute as a result of a user action. For example, you could modify the PL/SQL page process that logs the search phrases so that it logs phrases only when the current user is an administrator by using the authorization scheme rather than using a condition. In this particular scenario, you would not get a warning message when nonadministrators perform a search (unlike when they try to access a page protected by the same authorization scheme), but the PL/SQL process would not be processed at all. By using the authorization scheme rather than a condition, you again have the benefit of being able to decide whether the scheme is checked on every page view or the cached value should be used.

To Cache or Not to Cache Please excuse the corny title of this section, but it does describe the topic: deciding whether to evaluate authorization schemes on every page view or just once per session. In this chapter’s example, the USER_IS_ADMIN authorization scheme is evaluated only once per session. This means that the value is cached the first time it needs to be evaluated after a new session is established (which would usually occur after the user successfully authenticates to the application). So if a nonadministrator, such as the tim user, authenticates to the application, he will not see the Create link. But what if you modify that user so that he is now an administrator, as shown in Listing 3-7? Listing 3-7. Modifying the brian User to Be an Administrator apexdemo@10gR2> update user_repository 2 3

set admin = 'Y' where username = ‘brian’;

1 row updated. apexdemo@10gR2> commit; Commit complete.

132


This user will still not see the Create button, even if he navigates away from the page and then returns to it. You would need to tell the user to log out and then back in again in order for his new administrator privileges to be recognized by the application. To avoid this, you could modify the authorization scheme so that it is evaluated on each page view. Then the next time the user performs an action that displays a page that references the authorization scheme, the authorization scheme will be reevaluated. In this case, the user’s new administrator privileges would be recognized, so he would not need to log out and log back in. As noted earlier, the downside to having authorization schemes reevaluated each time the page is displayed is performance. For example, imagine that your application has quite a large user repository and attracts perhaps 1,000 different users throughout the day, each viewing 10 different pages, each with a reference to your authorization scheme. That would mean that throughout the course of the day, your authorization scheme is evaluated around 10,000 times. Using once per session evaluation instead potentially reduces the number of queries the database needs to handle in a day by around 9,000 (to around 1,000 times a day—once for each user, assuming a user logs in for only a single session). You might say, “So what? The query was running really quickly anyway!” Don’t forget that anything you do in a multiple-user system can impact other sessions running in that database. So even if your query runs blisteringly fast, if you don’t need to do it, then don’t. Your individual business requirements should determine whether every page view or once per session is best for that particular authorization scheme. In the example, promoting users to administrator status won’t happen very often, so you don’t need to reevaluate that check every time a page is viewed; once per session is a reasonable choice. Reevaluating your authorization schemes more often than necessary not only gives the database more unnecessary work to do, but may also negatively impact the impression your end users have of the application, if the pages take longer to refresh than they should.

Resetting the Caching There is actually an alternative to making the user log out and then back in again when your authorization scheme is set to reevaluate once per user session. You can invalidate the caching of the authorization scheme values in the current APEX session with the following call: apex_util.reset_authorizations; This will force the authorization schemes to be evaluated again the next time they are referenced. As an example, suppose you added a new Reset Auths button to the report page, and also added a new PL/SQL page process that makes a call to apex_util.reset_authorizations whenever the Reset Auths button is clicked. Now if the brian user (who is not an administrator) logs in to the application, he will see the screen shown in Figure 3-43. Notice that the report columns are still being hidden by conditions applied to the individual columns, rather than by the authorization scheme. Here, you are concerned only with the status of the Create button, since that page item is using the IS_ADMIN_USER authorization scheme.

133


Figure 3-43. Nonadministrators can’t see the Create button but can see the new Reset Auths button. Now suppose you update the user_repository table to make the brian user an administrator (see Listing 3-7) while he is still logged in, and he navigates back to the report page. Figure 3-44 shows that the report columns will now be displayed (since they were being hidden by a condition, which does pick up the change to the admin flag for the user), but the Create button is still hidden, since the cached value for the authorization scheme is being used.

Figure 3-44. The authorization scheme is still caching the old value. If brian now clicks the Reset Auths button (which will call the apex_util.reset_authorizations routine), he is redirected back to the same page, and the authorization scheme value is reevaluated (having been invalidated by the call to reset_authorizations). Figure 3-45 shows that the Create button is now correctly displayed for the user.

134


Figure 3-45. Calling apex_util.reset_authorizations forces the reevaluation. Clearly, this is not a solution you’d use in your production applications, since it would be almost as inconvenient to have users click the Reset Auths button as it would to have them log out and then back in again. However, you could make a call to the apex_util.reset_authorizations routine in other ways. It gives you many different alternatives to forcing the user to authenticate to the application again. For example, you could write a process that calls the reset_authorizations procedure only if X number of minutes have elapsed since the last time a call was made to it, or you could have a process that checks a table for a flag that determines whether the authorizations should be invalidated.

Summary In this chapter, you learned about conditions and authorization schemes. Be sure that you understand the difference between the two. Use authorization schemes as a security mechanism to control access to different parts of your application. Use conditions to control the flow of processing, or to control the display of elements on a page when security is not an issue. For example, if you wish to display a certain button only on the first of the month, use a condition. But if you want to restrict access to that button to certain users, use an authorization scheme. Don’t fall into the trap of enforcing security through conditions, because you might discover that your security is really an illusion. Review the section “Protecting Your Resources” if you have any doubts as to when to use conditions versus authorization schemes.

135

CHAPTER 4

Data Security The previous chapter dealt with using conditional display and authorization schemes to control which data users can access and modify. However, even when you use both of these methods, users may still be able to gain access to data that they should not be able to view, or even worse, be able to modify or delete that data. This chapter covers other methods, such as Session State Protection (SSP), you can use to help secure your application against potential misuse by a user (either intentionally or unintentionally). We will also look at using database features, such as Virtual Private Database (VPD), which is sometimes referred to as Fine-Grained Access Control (FGAC). Features such as VPD let you apply access controls at the database level, rather than at the application level.

URLs and Security You will rarely need to construct URL syntax yourself, since APEX makes it easy to link to other pages and pass session information without manually constructing a URL. However, knowing exactly how a URL is built lets you see how someone could manipulate the URL to modify data or to access a part of your application he shouldn’t be able to access.

Understanding the URL Syntax One of the first things that users new to APEX often comment on is that the format of the URL seems a little untidy compared to other web development tools. For example, the following is a URL from the Buglist application: http://127.0.0.1:8080/pls/apex/f?p=107:2:34396854152511::::P3_ID:2 At first glance, the URL seems difficult to decipher. However, the URL follows a structured syntax, which makes sense once you understand how it is constructed. The sample Buglist URL can be broken down into the following components: 127.0.0.1: The IP address of the server on which the web server is running. This could be a hostname instead. 8080: The port number on which the web server is listening. /pls: Indicates that the request is to be handled by the mod_plsql handler. /apex: The DAD name that you have specified in the configuration files. The DAD contains details about which database instance to connect to, as well as which user to connect as.

137

CHAPTER 4 ■ DATA SECURITY

f?p=: Represents the core procedure that is called for APEX pages. The procedure is called f and contains a number of parameters. The sample URL passes only one parameter, called p. 107: The application ID that is being accessed. 2: The page number of the application. 34396854152511: The session number. P3_ID: The name of a page item. 2: The value to which to set the associated page item. The general format of the URL is as follows: f?p=App:Page:Session:Request:Debug:ClearCache:itemNames:itemValues:PrinterFriendly where: App: The numeric application ID or alphanumeric application alias. Page: The numeric page ID or alphanumeric page alias. Session: The numeric session ID, which enables session state information to be maintained between page views by a user. The session ID can be referenced using the following syntax: • Substitution string: &SESSION. • PL/SQL: v('SESSION'). • Bind variable: :APP_SESSION. Request: The value of the REQUEST session item, which can then be referenced during the accept phase of the page processing. For example, you can determine which button was pressed by referencing the value of REQUEST. You can reference REQUEST using the following syntax: • Substitution string: &REQUEST. • PL/SQL: v('REQUEST') • Bind variable: :REQUEST Debug: A flag to determine whether the page should be run in debug mode. It can be set to YES (to display the debugging details) or NO. You can reference the debug flag using the following syntax: • Substitution string: &DEBUG. • PL/SQL: v('DEBUG'). • Bind variable: :DEBUG. ClearCache: Allows items in the session cache to be cleared (the values are set to NULL). The value depends on exactly what you wish to clear, such as: •

138

To clear cached items on an individual page, specify that page number.


•

To clear cached items on multiple pages, specify the page numbers in a commaseparated format.

•

To reset collections, specify individual collection names (or a comma-separated list of collection names).

•

To reset the pagination on the requested page (if you wish to reset the pagination on a previously viewed report, for example), use the keyword RP.

•

To clear the cache for all pages and all application items in the current application, use the keyword APP.

•

To clear any items associated with all applications that have been used in the current session, use the keyword SESSION.

itemNames: A comma-separated list of item names that are used to set session state. itemValues: A comma-separated list of item values that are used to set session state. These values are passed in the same order as the item names. You can’t pass a value that includes a colon (since that would be parsed as a URL delimiter); you would need to escape the colon character or use an alternative character and then substitute it back for a colon in your code. You may pass a comma in the item value, but you must enclose the characters with backslashes, as in \Smith, Bob\. PrinterFriendly: Specifies whether the page is being rendered in printer-friendly mode. If this value is set to YES, the page is rendered in printer-friendly mode. You can reference the value of PrinterFriendly in your page processing to determine which elements to display to make the page look better when printed.

Manipulating the URL You might feel that the URL gives away too much information in the users’ browser. In other words, since the URL displays some of the internal logic you’re using (such as the item names), could malicious users exploit this to their advantage? The answer, unsurprisingly, is yes they could. As an example, let’s take a look at the Buglist application again. Figure 4-1 shows the Update Bug screen.

 Note The part of the URL that specifies the port number (for example, port 8080) is easy to hide, as you will see in Chapter 15.

139


Figure 4-1. Updating a bug in the Buglist application In this case, we’re using the Embedded PL/SQL Gateway, so you don’t see the /pls in the URL. Here’s the URL that brought us to this page: http://192.168.56.101:8080/apex/f?p=101:3:2038098154500779::::P3_ID:1 Here, the itemNames parameter contains a single item (P3_ID), and the itemValues parameter contains a single value (1). In other words, when this page is called via that URL, the P3_ID page item will be set to a value of 1. The value of the P3_ID page item is used in the page to determine which record to retrieve and display to the user. Usually, you would want the user to go back to the previous page with the list of records and select a new one to edit. However, as you saw in the example of changing the page number in the URL in the previous chapter, it’s possible for users to manipulate the URL directly. To test this with the P3_ID value, simply change the value of 1 to 2 and enter the new URL into the browser’s address bar, as shown in Figure 4-2.

140


Figure 4-2. Modifying the URL directly to alter the P3_ID value By manually setting the value of the P3_ID page item, you can retrieve a different record. In this example, URL manipulation lets you access records you were able to access anyway, so the fact that the user can modify the URL manually might not seem like all that big of a deal. However, if you make some changes to the Buglist application to make it a bit more realistic in terms of the different levels of data access that people might have, the potential issues related to URL manipulation should become a bit clearer. First, instead of allowing the user to enter a free-format name into the Assigned To field, we’ll make that field a list of people contained in the user_repository table. To do this, we’ll create a new LOV that returns the list of users in the user_repository table, as shown in Figure 4-3. The query to use for the LOV is shown in Listing 4-1.

141


Figure 4-3. Creating the LOV_USERS LOV Listing 4-1. LOV Query to Return Usernames in the user_repository Table select initcap(forename) || ' ' || initcap(surname) as fullname, username as username from user_repository order by surname

 Note Listing 4-1 uses the InitCap function here to format the forenames and surnames returned by the query. The InitCap function might not work nicely on all names (for example, the surname McMaster ends up being formatted as Mcmaster), so you probably want to take this into account in your own systems.

You can now change the P2_ASSIGNED_TO page item to be a select list, as shown in Figure 4-4, which is based on your new LOV, shown in Figure 4-5.

Figure 4-4. Changing the Assigned To field to a select list

142


Figure 4-5. Basing the P3_ASSIGNED_TONAME page item on LOV_USERS If you run the page again, you can see that the Assigned To field presents you with a list of users you can select from, as shown in Figure 4-6.

Figure 4-6. The list of users you can select from The problem now is that in the buglist table, the assigned_toname field actually contains the old free-format text rather than the username from the LOV. Also, if you set a new Assigned To value from the Update Bug screen, the value shown in the report on the home page will be the username (see Figure 4-7), rather than the nicely formatted full name that appears in the select list. You could change the LOV so that it stores the nicely formatted name; however, you want it to store the username for a reason that will become clear in a moment.

143


Figure 4-7. Bug report showing the incorrect Assigned To value You can display the correct value in the bug report by editing the Assigned To column in the report (the Column Attributes section of the report). Change the Display As field from Standard Report Column to “Display as Text (based on LOV, does not save state),” as shown in Figure 4-8, and then assign the LOV_USERS LOV that you created earlier.

Figure 4-8. Changing the report Assigned To field to use the LOV In the LOV attributes, set Display Extra Value to Yes, as shown in Figure 4-9. This means that the report will still display any names in the Assigned To column that don’t also appear in the LOV. With this field set to No, the Assigned To column defaults to showing the first entry in the LOV, which is probably not desirable behavior in this case.

144


Figure 4-9. Displaying values that don’t appear in the LOV You have now changed the report so that it displays the full name of the user the record is assigned to (as it did before), while the Update Bug screen allows you to select a user from a list when assigning the bug. Now let’s extend the example a bit more. Suppose you want to implement a business rule that says that when users log in to the application, they can see only the bugs that are assigned to them. The exception is administrators, who are allowed to see all bugs. You can enforce this rule simply by modifying the query used for the report on the home page to take the logged-in username into account, as shown in Listing 4-2. Listing 4-2. Modified Report Query to Include Additional Restrictions select "ID", "BUGID", "REPORTED", "STATUS", "PRIORITY", "DESCRIPTION", "REPORTED_BY", "ASSIGNED_TO" from "BUGLIST" where ( instr(upper("STATUS"), upper(nvl(:P1_REPORT_SEARCH,"STATUS"))) > 0 or instr(upper("PRIORITY"), upper(nvl(:P1_REPORT_SEARCH,"PRIORITY"))) > 0 or instr(upper("DESCRIPTION"), upper(nvl(:P1_REPORT_SEARCH,"DESCRIPTION"))) > 0 or

145


instr(upper("REPORTED_BY"), upper(nvl(:P1_REPORT_SEARCH,"REPORTED_BY"))) > 0 instr(upper("ASSIGNED_TO"), upper(nvl(:P1_REPORT_SEARCH,"ASSIGNED_TO"))) > 0 ) and ( (upper(assigned_to) = :app_user) or exists (select 1 from user_repository where upper(username) = :app_user and admin = 'Y') )

or

Remember that the query in Listing 4-2 was generated by the application creation wizard. The reason for the references to instr is to allow the query to return the correct results if the user entered anything into the P1_REPORT_SEARCH field. You just need to add a where clause restriction, which checks if the uppercased ASSIGNED_TO column matches the currently logged-in username (remember that the :APP_USER bind variable will automatically be in uppercase, hence the need to uppercase the ASSIGNED_TO value). You also use an exists clause to check if the currently logged-in user is an administrator. If the logged-in user is an administrator, the query will return all records (that match the search criteria); otherwise, only records that are assigned to the user (and which match the search criteria) will be returned. If you now run the application again while logged in as the user john (who is an administrator), you will see all the records. If you log in as the user brian (who is not an administrator), you will see only the records that have been assigned to that user, as shown in Figure 4-10.

Figure 4-10. Report restricted to showing entries assigned to the logged-in user So user brian can now see only the single record that has been assigned to him. If he chose to edit that record, he could actually assign it to someone else, and then he would not see any records in the report (until an administrator assigned some bugs to him). However, there is still a slight loophole in the Update Bug screen: the Next and Previous buttons allow the user to view records that aren’t assigned to him. We could simply remove those buttons to solve that problem; however, for the moment, we will just ignore them. The main point of this example is that it represents the way many people might implement securityaccess restrictions in their applications: restrict a set of records shown in a report and assume that any modification screens can be accessed only via a valid link from another screen. The flaw in this scheme is that knowledgeable users can manipulate the URL. For example, all brian needs to do is to change the

146


link on the Update Bug screen and try setting the value of the P3_ID item to a different value, as shown in Figure 4-11. This user can completely bypass the restriction and access records assigned to other users. (The Assigned To field in Figure 4-11 shows Mark Wilson because it is pulling the record related to the value in the URL. This record is actually assigned to a user not listed in the LOV.

Figure 4-11. URL manipulated to access other records You could just change the code you’re using in the Update Bug screen to perform an additional check to determine whether the user should be able to access the record. While this could work, there is another way you can prevent this particular problem. This method is known as Session State Protection.

Session State Protection Session State Protection (SSP) is a way of protecting the information stored in the user session from direct, unauthorized manipulation. In other words, you can detect whether a user has manipulated the URL in an attempt to access or modify a particular session item. The default when you create a new application is for SSP to be disabled. When you enable SSP, the URLs that are used to navigate between pages in your application will also include checksums to prevent tampering with item values in session state. There are very few reasons, other than for the simplest demonstration applications, why you wouldn’t enable SSP in your applications, particularly if an application is going to be used to access confidential or valuable data. Using SSP is an extremely powerful way to protect your application against malicious (or even accidental) URL manipulation. As you will see, even just accepting the defaults provided by the wizard makes your application far more secure and resistant to manipulation. You should consider SSP, along with authentication and authorization schemes, as part of your core defenses in securing your application and data.

147


To take advantage of SSP, you need to enable the feature in your application, and then define which page and items you want to protect. You can define SSP against pages, page items, and application items.

Enabling Session State Protection You can access the SSP settings for your application either via the Security Attributes section of the Application Attributes, as shown in Figure 4-12, or via the Session State Protection section of the Shared Components for your application, as shown in Figure 4-13. Clicking the Manage Session State Protection button in the Security Attributes section takes you to the same screen as the Shared Components Session State Protection screen (Figure 4-13). Here, you can access the SSP settings for particular pages, items, and application items directly, or you can access them via a wizard by clicking the Set Protection button.

Figure 4-12. Accessing SSP from the Application Security Attributes

Figure 4-13. Accessing SSP from Shared Components

148 3


To enable SSP, click the Set Protection button. This takes you to the screen shown in Figure 4-14. From here, you can choose to disable, enable, or configure SSP. Choose Enable, and then confirm that choice, as shown in Figure 4-15.

Figure 4-14. Using the SSP wizard

Figure 4-15. Enabling SSP via the wizard Well, that was quick and painless! So what has it done? If you log in again as brian and manipulate the URL on the Update Bug screen, you will see that you are still able to access records that user should not be able to access. This is because although you have enabled SSP, you haven’t yet specified which items you want protected.

Configuring Session State Protection To configure SSP, choose Configure in the wizard. You will see the screen shown in Figure 4-16.

149


Figure 4-16. Configuring SSP via the wizard This page allows you to define settings for page and item attributes. For now, just accept the default settings and apply the settings in the wizard. Now the interesting part! Run the test as before (log in to the application as user brian and try to manipulate the URL on the Update Bug screen). Rather than being able to see records that you shouldn’t be able to access, you will see a screen similar to Figure 4-17.

Figure 4-17. SSP issuing an error So what has happened here? If you examine the URL that was used, you’ll see that an additional parameter has been added (the session ID is shortened to 123 here just for readability of the example): f?p=101:3:10418706087826::::P3_ID:2&cs=3B42C26E01AD2D98A2ABC4B46F0AE4470 The cs parameter is the checksum, which is calculated based on the items and values that have been set by the application when building the URL. This checksum is then recalculated when the new page is being processed, and if the recalculated checksum does not match the checksum passed in the URL, an error is raised. So, with very little effort, you have prevented users from being able to modify the URL to access records they shouldn’t be able to access. If you look back at the settings that were made for your application by the SSP wizard, you’ll see that for the Update Bug screen, each page item is set to Checksum Required – Session Level, as shown in Figure 4-18. Therefore, when the user tries to modify the value of the P3_ID page item, which is protected by a checksum, the SSP functionality kicks in and issues the error you saw.

150


Figure 4-18. Page and item protection in the wizard Now that you’ve seen how to protect your application from URL manipulation by using the defaults in the wizard, let’s look at the four attribute categories you can protect with SSP: •

Page access

•

Application item

•

Page data entry item

•

Page display-only item

Page Access Protection Page access protection allows you to define SSP values for pages. You can select from the following values: Unrestricted: The page can be requested directly using a URL, either with or without session state arguments (such as page items and values, cache clearing, and so on). Arguments Must Have Checksum: If any arguments are passed in the URL, a corresponding checksum must also be provided. No Arguments Allowed: The page can be requested via a URL, but no request, clear cache, or page item and values are allowed in the URL. No URL Access: The page can’t be accessed directly using a URL. The page may be accessed only as the target of a page branch, which does not perform a URL redirect.

151


In the example, the Update Bug screen was set to use Arguments Must Have Checksum; however, you can see how using the No Arguments Allowed or No URL Access settings could be extremely useful. For example, if you have a page in your application that you don’t want users to be able to access directly—it should be accessible only via a page branch from another page—you could use the No URL Access setting for that particular page.

Application Item Protection Application item protection allows you to define SSP values for application items. You can choose from the following values: Unrestricted: The session state for the application item can be set by passing the item name and value via the URL or by posting it via a form. No checksum is passed in the URL. Restricted: The session state for the application item may not be set from the browser. The session state for the application item can’t be set via the URL or by being posted via a form. The only way to set the item value is through internal processes, computations, and so on. This is applicable only to items that can’t be used as data-entry items and is always active, even if SSP is disabled. This setting can be used for application items and for pages items with any of the Display As types, such as the following: •

Display as Text (escape special characters, does not save state)

•

Display as Text (does not save state)

•

Display as Text (based on LOV, does not save state)

•

Display as Text (based on PLSQL, does not save state)

•

Text Field (Disabled, does not save state)

•

Stop and Start HTML Table (Display label only)

Checksum Required – Application Level: The application item may be set via the URL only if the item name and value are accompanied by a checksum that is specific to the workspace and application; however, a user-level checksum or session-level checksum will also enable the application item to be set. This should be used when you want the item to be set via the URL by any user running the same application in the same workspace but using different sessions. Checksum Required – User Level: Similar to the Application Level checksum in that the application item may be set via the URL as long as a checksum accompanies the item name and value; however, the checksum needs to be specific to the workspace, application, and user. A session-level checksum will also work, but an application-level checksum will not work. This should be used when you want to allow the item to be set via the URL where the checksum was generated by the same user running the same application in the same workspace but in a different session.

152


Checksum Required – Session Level: Similar to the User Level checksum in that the application item may be set via the URL only if a checksum accompanies the item name and value; however, the checksum must be specific to the current session. This should be used when you wish to allow the application item to be set by URLs only when the checksum was generated in the same session. Which value to select for application-item protection depends on your particular situation. Many times, you may find that the default of using Checksum Required – Session Level is sufficient for your needs.

Page Data Entry Item Protection Page data entry item protection allows you to define SSP values for page items that are used for data entry. The following values are available: Unrestricted: The session state for the page item may be set by passing the item name and value via the URL or by being posted via a form. No checksum is required in the URL. Checksum Required – Application Level: The session state for the page item can be set via the URL as long as the item name and value are accompanied by a checksum that is specific to the workspace and application. A user-level checksum or session-level checksum is also sufficient. This should be used when you want to allow the page item to be set by URLs that include a checksum generated by any user running the same application in the same workspace but in a different session. Checksum Required – User Level: The session state for the page item can be set via the URL as long as the item name and value are accompanied by a checksum that is specific to the workspace, application, and user. A session-level checksum will also be sufficient. This should be used when you want to allow the page item to be set via a URL that includes a checksum that was generated by the same user running the same application in the same workspace but in a different session. Checksum Required – Session Level: The session state for the page item can be set via the URL as long as the item name and value are accompanied by a checksum that is specific to the current session. This should be used when you want to allow the item to be set only by a URL that includes a checksum generated within the same session.

Page Display-Only Item Protection Page display-only item protection allows you to define SSP values for page items that are used for display-only purposes. You can set the following values: Unrestricted: The session state for the page item may be set by passing the item name and value via the URL or by being posted via a form. No checksum is required in the URL. Restricted: The session state for the page item may not be set from browser, or via the URL or by being posted from a form. This should be used when you wish to prevent the page item from being set by anything other than internal processes, computations, and so on. This is always active, even if SSP is disabled. This can be used for any of the following Display As types: •

Display as Text (escape special characters, does not save state)

•

Display as Text (does not save state)

153


•

Display as Text (based on LOV, does not save state)

•

Display as Text (based on PLSQL, does not save state)

•

Text Field (Disabled, does not save state)

•

Stop and Start HTML Table (Displays label only)

Checksum Required – Application Level: The session state for the page item may be set via the URL only if the item name and value are accompanied by a checksum that is specific to the workspace and application. A user-level or session-level checksum will also be sufficient. This should be used when you wish to allow the page item to be set by URLs that have a checksum that is generated by any user running the same application in the current workspace but in a different session. Checksum Required – User Level: The session state for the page item may be set via the URL only if the item name and value are accompanied by a checksum that is specific to the workspace, application, and user. A session-level checksum will also be sufficient. You should use this when you want to allow the page item to be set via URLs that have a checksum that is generated by the same user running the same application in the same workspace but in a different session. Checksum Required – Session Level: The session state for the page item may be set via the URL only if the item name and value are accompanied by a checksum that is specific to the current session. You should use this when you want to allow the page item to be set via URLs that have a checksum that was generated in the same session.

A Note About Bookmarks You might be wondering how using SSP will affect users who have bookmarked a link to your application. The following situations apply: •

Any bookmarked links created after SSP was enabled will work if the bookmarked link contains a checksum.

•

Any bookmarked links created before SSP was enabled will not work if the bookmarked link contains a checksum.

•

SSP will not affect any bookmarks that do not contain checksums or that contain unnecessary checksums. The validity of the bookmarks will be determined by other criteria.

You can expire any bookmarks created before SSP was enabled, or expire any bookmarked URLs that contain previously generated checksums, by using the Expire Bookmarks button in the Session State Protection section of the application Security Attributes page.

Virtual Private Database One of the benefits of using APEX to design and implement your applications is that you can implement access control policies at the database level rather than at the application level. If you are using the Enterprise Edition of the database, you can use the Virtual Private Database (VPD) feature (also known as Fine Grained Access Control, or FGAC).

154


In essence, VPD enables queries to be rewritten on the fly to include additional predicate information. The additional predicate information is determined from a security policy that you implement as a PL/SQL function; the function returns the additional predicate logic to be used in the where clause of the query. The security policy is then registered against the tables you wish to protect with VPD. So why would you want to use this feature? Here are several reasons: •

It helps you separate security logic from application logic. By putting the security logic into the database, rather than in the application, you centralize the logic of how the underlying data should be accessed. This centralized logic can then easily be shared among different applications without you having to code additional logic into each application. In other words, since the security logic is implemented at the database level, it will occur transparently as far as the applications are concerned; users will be able to access only the data they are allowed to access.

•

It increases the degree to which you can audit the data changes within your application. By using VPD, you can have a security policy (or set of policies) that present different views of the data depending on the logged-in user.

•

It makes it far easier to incorporate changes to your security logic. Rather than needing to change your logic in multiple places in multiple applications, you just need to modify it at the database level (or, rather, in your security policy function).

•

It can protect the data regardless of the method of access. In other words, if you implemented all of your security logic in your APEX application, you would also need to duplicate that logic in any Java applications that access the same data. Similarly, someone could just connect using SQL*Plus and modify the data directly, thereby circumventing the security logic of your application. By using the VPD functionality, you can protect the data no matter what application someone uses to connect to the database.

•

It allows for easier maintenance. By using centralized security policies, which you can apply to many different tables, you decrease the amount of duplicate code you need to write and also make it far easier to modify that code later.

The point about protecting the data regardless of the method of access is a very important one. It’s surprisingly common for people to modify data directly using tools such as SQL*Plus and TOAD, rather than using the in-house applications that were built specifically for the purpose. Using such tools circumvents any application, business, and security logic you’ve implemented in your application. By implementing as much logic as you can in the database, rather than in the application, no matter how a user modifies the data, you can still enforce the checks at the database level.

Implementing VPD In the Buglist application, the list of bugs shown in the report is currently restricted by specifically including a where clause restriction in the query used in the report (see Listing 4-2). The query includes the predicate: and ( (upper(assigned_to) = :app_user) or exists (select 1 from user_repository

155


where upper(username) = :app_user and admin = 'Y') Imagine that a number of different applications—some written in APEX and others written in languages such as Java—query and operate on the data in this table. Each application that accesses the data in that table would also need to incorporate the same predicate; otherwise, the security logic would not be equivalent across all the different applications. Also, if you wanted to change the way the security logic was implemented, you would need to change it in each query in each application. To demonstrate the point, let’s create a new database user and give that user permission to select the data from the buglist table (the table queried in the report). Name the new database user brian, so that you can compare what happens when brian logs in to the Buglist application and runs the report versus what he can see when he logs in to the database as the brian user using SQL*Plus. As shown in Listing 4-3, create the brian user, then grant him create session permission so he can connect to the database and select permission on the buglist table in the APEXDEMO schema. Listing 4-3. Creating the brian Database User sys@DBTEST> create user brian identified by ardvark 2 3

default tablespace users temporary tablespace temp;

User created. sys@DBTEST> grant create session to brian; Grant succeeded. sys@DBTEST> grant select on apexdemo.buglist to brian; Grant succeeded. Now, using SQL*Plus, connect to the database as the brian user and query the buglist table. brian@DBTEST> select count(*) from apexdemo.buglist; COUNT(*) ---------18 As you can see, brian can see every record in the table. However, you actually want him to be able to see only the records that have been assigned to him. To make that happen, you need to define your policy function.

Defining the Policy Function The policy function needs to accept two VARCHAR parameters: one for the schema owner and the other for the object name. The function also needs to return a VARCHAR string, which is the string to be used in the new predicate. The function prototype should look like this: function policy_function_name(owner in varchar2, object_name in varchar2) return varchar2

156


If you again connect as the APEXDEMO user in SQL*Plus (since you are protecting the data in that schema), you can create a simple function that returns the string you need, as shown in Listing 4-4. Listing 4-4. Creating the Policy Function apexdemo@DBTEST> create or replace function vpd_buglist( 2 3 4 5 6 7 8 9 10 11 11 12

p_schema in varchar2 default null, p_object in varchar2 default null) return varchar2 as begin return '( upper(assigned_to) = nvl(v(''APP_USER''), USER) or exists (select 1 from user_repository where upper(username) = nvl(v(''APP_USER''), USER) and admin = ''Y''))'; end; /

Function created. This function simply returns a string, but notice that you must change the string slightly from the string you used in the original report query: instead of using :APP_USER to determine the username, you use nvl(v('APP_USER', USER). This is because :APP_USER will return only the username when the user has connected to the database via the APEX application. For the policy function to correctly determine the username when the user is connected via SQL*Plus (or some other application where the user connects as a database user), you need to use the USER function. The nvl(v('APP_USER'), USER) determines if the v('APP_USER') is a non-null value; that is, the user is connected via an APEX application. If so, you use the value returned by v('APP_USER'). If not, you use the value returned by USER. Now that you’ve defined your policy function, you need to apply it to the buglist table, using the DBMS_RLS package. You use DBMS_RLS to link the policy you just defined to a particular schema object. First, grant the execute permission on DBMS_RLS to the APEXDEMO user: sys@DBTEST> grant execute on dbms_rls to apexdemo; Grant succeeded. Next, connect again as the APEXDEMO user and add the policy against the buglist table, as shown in Listing 4-5.

157


Listing 4-5. Applying the Policy Using DBMS_RLS apexdemo@DBTEST> begin 2 3 4 5 6 7 8 9 10

dbms_rls.add_policy( object_schema => 'apexdemo', object_name => 'buglist', policy_name => 'Buglist Policy', function_schema => 'apexdemo', policy_function => 'vpd_buglist', statement_types => 'select'); end; /

PL/SQL procedure successfully completed. You apply the policy using the DBMS_RLS.ADD_POLICY procedure, which accepts a number of different parameters that allow you to define the schema and object name to which you wish to apply the policy, as well as the schema and function you wish to apply. Note that in this example, for simplicity, the policy function is defined in the same schema that contains the objects we’re trying to protect. In practice, this is not recommended, as explained in the “VPD Best Practices” section later in this chapter. It’s better and safer to define your policy functions in schemas separate from your data.

 Note The RLS in DBMS_RLS stands for Row Level Security, which is where VPD and FGAC evolved from. You will often hear people referring to RLS, VPD, and FGAC interchangeably. All three acronyms essentially refer to the same sort of technique.

Now when you reconnect to the database as brian using SQL*Plus and query the buglist table in the APEXDEMO schema, you will see something interesting: brian@DBTEST> select count(*) from apexdemo.buglist; COUNT(*) ---------1 You can see only one record now. To confirm that you’re actually seeing records assigned to brian, select some columns from the table: brian@DBTEST> select id, bugid, reported, status, assigned_to 2

158

from apexdemo.buglist;


ID

BUGID REPORTED

STATUS

ASSIGNED_TO

------ ------- --------- --------------- ---------------2 2 01-FEB-06 Open brian So, the policy function is being applied correctly if you connect via SQL*Plus. What about when you log in via your APEX application? Before trying that, you need to remove the predicate from the report query, as shown in Figure 4-19. Otherwise, you’ll end up applying the predicate twice: once as part of the query and once due to the policy.

Figure 4-19. Removing the predicate from the report query If you now run the application again and connect as the brian user (remember this is not the same as connecting as the brian database user), you see that the VPD policy is still being applied correctly, as shown in Figure 4-20.

159


Figure 4-20. The VPD policy working through the application Now connect to your application as the user john, who is an administrator. You will be able to view all of the records, as shown in Figure 4-21.

Figure 4-21. The application administrator can still see all the records. If you edit one of these records and assign it to the brian user and then return to your SQL*Plus session and query the buglist table again, you will see that the new record is available:

160


brian@DBTEST> select id, bugid, reported, status, assigned_to 2


ID BUGID REPORTED STATUS ---- ------ --------- -------2 2 02-JAN-06 Closed 11 11 02-AUG-06 Open

ASSIGNED_TO -----------------------------brian brian

So, no matter which application you use to modify the data, your policy function makes sure that other applications connected as that user see the correct data.

Closing the Loopholes When you applied your policy function (Listing 4-5) to the table, you set the statement_types parameter to select. This means that the policy function will be applied only when a select statement is performed against the table. Since you granted only select permission to the brian user, that isn’t an issue. But what would happen if brian also had delete and update permissions on the buglist table: apexdemo@DBTEST> grant update, delete on buglist to brian; Grant succeeded. You can now connect as brian and see what happens when you try to delete a record from the buglist table: brian@DBTEST> select count(*) from apexdemo.buglist; COUNT(*) ---------2 brian@DBTEST> delete from apexdemo.buglist; 18 rows deleted. brian@DBTEST> select count(*) from apexdemo.buglist; COUNT(*) ---------0 brian@DBTEST> rollback; Rollback complete. brian@DBTEST> select count(*) from apexdemo.buglist; COUNT(*) ---------2

161


Well, clearly there’s a bit of a problem here. brian is able to view only the 2 records assigned to him, which is correct; however, he is able to delete all 18 records in the table. Similarly, brian would be able to update all 18 records rather than just the 2 records assigned to him. Fortunately, this loophole in permissions is easy to close. You can use the same policy function you created earlier and apply it to all select, update, and delete statements against the buglist table. First, drop the existing policy, as shown in Listing 4-6. Listing 4-6. Dropping the Existing Policy apexdemo@DBTEST> begin 2 3 4 5 6 7

dbms_rls.drop_policy( object_schema => 'apexdemo', object_name => 'buglist', policy_name => 'Buglist Policy'); end; /

PL/SQL procedure successfully completed. Then create the new policy against select, update, and delete statements, as shown in Listing 4-7. Listing 4-7. Creating a New Select, Update, and Delete Policy apexdemo@DBTEST> begin 2 3 4 5 6 7 8 9 10

dbms_rls.add_policy( object_schema => 'apexdemo', object_name => 'buglist', policy_name => 'Buglist Policy', function_schema => 'apexdemo', policy_function => 'vpd_buglist', statement_types => 'select, update, delete'); end; /

PL/SQL procedure successfully completed.

 Note Instead of dropping the old policy and creating a new policy with the new statement_types parameter values, you could just create a new policy for the update and delete statements, or even create a separate policy for each type of operation. However, it’s quite rare to want to give users different views of the data depending on whether they’re performing an update, insert, select, or delete operation, so generally it’s better to define a single policy that covers multiple statement types where appropriate.

162


You can now repeat the earlier experiment with the brian user and try to delete all the records from the buglist table: brian@DBTEST> select count(*) from apexdemo.buglist; COUNT(*) ---------2 brian@DBTEST> delete from apexdemo.buglist; 2 rows deleted. brian @DBTEST> rollback; Rollback complete. brian @DBTEST> update apexdemo.buglist set assigned_to = null; 2 rows updated. brian @DBTEST> rollback; Rollback complete. brian @DBTEST> select count(*) from apexdemo.buglist; COUNT(*) ---------2 With the policy now also in effect against update and delete statements, the users have a unified view of the data and can perform Data Manipulation Language (DML) statements only against records that have been assigned to them. You could use a similar policy to control the inserts that a user is able to perform against the buglist table. This policy is also being applied to the APEXDEMO user. If you connect as the APEXDEMO user and try to query the table, you will see this: apexdemo@DBTEST> select count(*) from buglist; COUNT(*) ---------0 This is due to the fact that no records are assigned to the APEXDEMO user. If you want the APEXDEMO user to still be able to see all of the records, you can adapt the policy function to take this into account, as shown in Listing 4-8.

163 x


Listing 4-8. Modified Policy to Take the APEXDEMO User into Account apexdemo@DBTEST> create or replace function vpd_buglist( 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

p_schema in varchar2 default null, p_object in varchar2 default null) return varchar2 as begin if (USER = 'APEXDEMO') and (v('APP_USER') is null) then return ''; else return '( upper(assigned_to) = nvl(v(''APP_USER''), USER) or exists (select 1 from user_repository where upper(username) = nvl(v(''APP_USER''), USER) and admin = ''Y''))'; end if; end; /

Listing 4-8 just adds a check to determine if you’re connected as the Oracle user APEXDEMO (and you’re not running through the APEX application). If so, an empty string is returned to the predicate; that is, you will be able to see all of the records. With just a few simple steps, you have restricted access to the data that a user is able to view and modify. Using VPD where appropriate can drastically simplify your application design and make it easier to maintain and evolve the security logic against all applications accessing a particular set of data.

Using Contexts with VPD You have seen how you can easily create a policy function based on the username, since you can use nvl(v('APP_USER'), USER) to determine the username, regardless of how the user was connected to the database. But what if you want to use some other criteria? How could you do that so it would work in APEX, SQL*Plus, any Java applications, and so on? The answer lies in using application contexts, which allow you to set custom information linked to a particular session that can then be used in the VPD policy. There are two types of contexts: Application context: This type of context is private to a particular session and will expire once the session ends. An application context is useful in a stateless environment, where the session state needs to be reestablished each time the session reconnects. Application contexts are stored in the User Global Area (UGA). Global application context: This sort of context can be shared across different sessions and will still exist after the session has ended. A global application context is not session-based and therefore allows you to maintain state information across multiple sessions. Global application contexts are stored in the System Global Area (SGA).

164


 Note The difference between the two types of contexts can appear subtle at first; however, they both have their uses. For more information, refer to the “Implementing Application Context and Fine-Grained Access Control” section of the Oracle Database Security Guide.

Creating and Setting Application Contexts When you use a tool such as SQL*Plus, you are already using contexts, because some have been set for you. For example, you can run the following query: apexdemo@DBTEST> select sys_context('USERENV', 'SESSION_USER') 2

from dual;

SYS_CONTEXT('USERENV','SESSION_USER') --------------------------------------------APEXDEMO Here, you use the sys_context function to access the value of SESSION_USER parameter within the USERENV context namespace. Other values are available within the USERENV namespace. Here’s an example: apexdemo@DBTEST> select sys_context('USERENV', 'MODULE') 2

from dual;

SYS_CONTEXT('USERENV','MODULE') --------------------------------------------SQL*Plus Querying the USERENV context namespace again, you retrieve the value of the MODULE parameter, which is set to the name of the application you are using to access the database—SQL*Plus, in this case. By creating your own application context, you can set a parameter to a particular value and then reference that value in your VPD policy function. Listing 4-9 demonstrates creating an application context. Listing 4-9. Creating an Application Context apexdemo@DBTEST> create or replace context vpd_context 2

using vpd_context_procedure;

Context created. This creates the application context and binds it to a procedure called vpd_context_procedure, which we have yet to write. By binding the context to this procedure, you are effectively saying that only the vpd_context_procedure will be allowed to set values in the context. If you allowed anyone to modify the values stored in the context, they would be able to easily circumvent any logic that you use in your

165


VPD policy. The purpose of tying the context to a particular procedure is to ensure that the values set in the context can come from only your procedure. As an example, let’s extend the VPD policy so that users see only the bug records assigned to them (unless they are an administrator) and only those records in a particular state: Open or Closed. First, create the vpd_context_procedure procedure, which will be used to set the context, as shown in Listing 4-10. Listing 4-10. Creating the Procedure to Set the Context apexdemo@DBTEST> create or replace 2 3 4 5 6 7 8 9 10

procedure vpd_context_procedure( p_status in varchar2 default null) as begin dbms_session.set_context('VPD_CONTEXT', 'STATUS', p_status); end; /

This procedure accepts a single parameter, p_status. Then, in the dbms_session.set_context procedure, it sets the value of the STATUS parameter in the VPD_CONTEXT context to the value passed into the p_status parameter.

 Note If you don’t already have execute permission on the DBMS_SESSION package, you’ll need to grant that permission before you are able to use the set_context packaged procedure.

You can now check that the vpd_context_procedure is successfully setting the context, as shown in Listing 4-11. Listing 4-11. Verifying the Procedure Sets the Context Correctly apexdemo@DBTEST> select sys_context('VPD_CONTEXT', 'STATUS') 2 from dual; SYS_CONTEXT('VPD_CONTEXT','STATUS') --------------------------------------------apexdemo@DBTEST> exec vpd_context_procedure(p_status => 'Open'); PL/SQL procedure successfully completed.

166


apexdemo@DBTEST> select sys_context('VPD_CONTEXT', 'STATUS') 2 from dual; SYS_CONTEXT('VPD_CONTEXT','STATUS') --------------------------------------------Open First, you query the value of the STATUS parameter in the VPD_CONTEXT context using the sys_context function to check that the context isn’t set yet. Next, you call the vpd_context_procedure and pass in a string parameter. Then you query the STATUS parameter again and see that the context has been successfully set. If you now disconnect from SQL*Plus, reconnect as the APEXDEMO user, and then run the query to check the value of the STATUS parameter in the VPD_CONTEXT, you will find that the value is empty. This is because the context was cleared when you terminated the session. Now you can rewrite the VPD policy function to use the value that was set in the context, as shown in Listing 4-12. Listing 4-12. Modified Policy Function to Use the Context Value 1

create or replace function vpd_buglist( 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

p_schema in varchar2 default null, p_object in varchar2 default null) return varchar2 as begin if (USER = 'APEXDEMO') and (v('APP_USER') is null) then return ''; else return '( upper(assigned_to) = nvl(v(''APP_USER''), USER) or exists (select 1 from user_repository where upper(username) = nvl(v(''APP_USER''), USER) and admin = ''Y'')) and upper(status) = sys_context(''VPD_CONTEXT'', ''STATUS'')'; end if; end;

Function created. All you have done here is add an extra part to the predicate that compares the status column in the buglist table against the value stored in the STATUS parameter of the VPD_CONTEXT. In order to try out the new policy function while connected as the brian user in SQL*Plus, you first need to grant execute rights on the vpd_context_procedure to brian: apexdemo@DBTEST> grant execute on vpd_buglist to brian; Now you can query the buglist table while connected as brian, and then set the application context and query the table again, as shown in Listing 4-13.

167


Listing 4-13. Using the Context Procedure to Affect the Policy brian@DBTEST> exec apexdemo.vpd_context_procedure('Open'); PL/SQL procedure successfully completed. brian@DBTEST> select count(*) from apexdemo.buglist; COUNT(*) ---------2 brian@DBTEST> exec apexdemo.vpd_context_procedure('Closed'); PL/SQL procedure successfully completed. brian@DBTEST> select count(*) from apexdemo.buglist; COUNT(*) ---------0 If you use the vpd_context_procedure to set the STATUS parameter to a value of Open or Closed, that value will be used in the policy function and will affect the view of the data that the user is able to access.

Using Application Contexts in an APEX Environment You have seen how you can use application contexts to influence the rules that are enforced by a VPD policy function. When you wish to use application contexts within the APEX environment, you need to be aware of an important factor:

The application context is valid only for the duration that the session is alive. The architecture of the APEX environment is that the connection to the database is achieved through the use of the mod_plsql connection pooling. You therefore have no guarantee that the database session that was used to process your last page request will be the same database session that is used to perform your next page request. APEX (and mod_plsql) ensures that the session and state information are set up correctly for each of your page requests, whether or not you get the same underlying database session connection. However, reestablishing custom application contexts is not handled for you automatically, so you will need to make provisions to handle those yourself. The easiest way to do this is to have a custom PL/SQL page process, or an application process that sets the value of the context on each page request. For example, in the Buglist application, you can change the report page so that it runs an anonymous PL/SQL block as a before header process, as shown in Figure 4-22, which simply executes the vpd_context_procedure and sets the parameter to Open. This way, the application context will be set to Open each time the page is executed.

168


Figure 4-22. Using a PL/SQL block to set the application context If you now run the report page, you will see that the report returns only records that are open and assigned to the brian user, as shown in Figure 4-23. If you click one of the records to edit it, you may get the error shown in Figure 4-24. This is because the database session used to process your page request might not be the same one that was used to process the report page; that is, the session does not have the context set. In this case, the automated row fetch process on the Update Bug page can’t retrieve the record, and the policy is applied without a status for comparison. To fix this, you can create the same type of before header PL/SQL process that you have on the report page, or alternatively, create an application process that executes for every page in the application.

169


Figure 4-23. The report returns only open bugs.

Figure 4-24. Error returned when trying to edit a record An alternative to using a page or application process to set the value stored in the context is to specify the PL/SQL in the security attributes of the application, as shown in Figure 4-25.

Figure 4-25. Setting a PL/SQL call to set the security context

170


Using Advanced VPD Features So far, you have seen how you can limit the set of records returned by using VPD and a policy function, with the policy applied to the entire row. Other features of VPD allow you to apply the policy based on the columns the user is attempting to access. Here, we will look at a couple of advanced VPD features you may find useful in your applications.

Column-Level VPD Policy Whereas your previous policy function applied to the entire row regardless of which columns the user was selecting, you can actually configure a policy that is applied only if the user is attempting to access certain columns. As an example, let’s set up the policy function so that the brian user is able to see all of the rows in the table unless he attempts to select the assigned_to field; in that case, he will be able to see only the rows assigned to him. So, as before, you need to create a policy function and then link it to the table using the DBMS_RLS package. First, let’s drop the old policy: apexdemo@DBTEST> begin 2 3 4 5

dbms_rls.drop_policy(object_name => 'buglist', policy_name => 'Buglist Policy'); end; /

PL/SQL procedure successfully completed. Now re-create the policy function as a much simpler one that just checks that the record is assigned to the user, as shown in Listing 4-14. Listing 4-14. Creating the New Policy Function apexdemo@DBTEST> create or replace function vpd_buglist( 2 3 4 5 6 7 8 9 10 11 12

p_schema p_object return begin if (USER return else return end if; end; /

in varchar2 default null, in varchar2 default null) varchar2 as = 'APEXDEMO') and (v('APP_USER') is null) then ''; 'upper(assigned_to) = nvl(v(''APP_USER''), USER)';

Function created. Like the previous policy function, this function checks to see if the user is connected as the Oracle user APEXDEMO. If so, it returns an empty string; otherwise, it returns a string that will compare the

171


assigned_to column with the logged-in user, whether the user is logged in via an APEX application or as an Oracle user. You can now apply the policy function using the DBMS_RLS.add_policy procedure, as shown in Listing 4-15. Listing 4-15. Applying the New Policy Function apexdemo@DBTEST> begin 2 3 4 5 6 7 8 9 10 11

dbms_rls.add_policy( object_schema => 'apexdemo', object_name => 'buglist', policy_name => 'Buglist Policy', function_schema => 'apexdemo', policy_function => 'vpd_buglist', statement_types => 'select, update', sec_relevant_cols => 'assigned_to'); end; /

PL/SQL procedure successfully completed. Notice that this time, we used an additional parameter in the call to the add_policy procedure. By using the sec_relevant_cols parameter and setting the value to assigned_to, you are saying that you want the policy to be enforced only if the assigned_to column is in the DML statement that is being used against the table. Now you can connect to the database via SQL*Plus as the brian user and check the effect of the new policy, as shown in Listing 4-16. Listing 4-16. Testing the New Policy -- perform a count of the records brian@DBTEST> select count(*) from apexdemo.buglist; COUNT(*) ---------2 -- count using the bugid column brian@DBTEST> select count(bugid) from apexdemo.buglist; COUNT(ID) ---------18 -- select using columns not part of the policy brian@DBTEST> select bugid, reported, reported_by 2 from apexdemo.buglist;

172


BUGID REPORTED ---------1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

--------27-JAN-06 01-FEB-06 02-AUG-06 03-FEB-06 03-FEB-06 05-FEB-06 06-FEB-06 06-FEB-06 07-FEB-06 07-FEB-06 08-FEB-06 08-FEB-06 09-FEB-06 09-DEC-05 10-FEB-06 10-FEB-06 11-FEB-06 11-FEB-06

REPORTED_BY -----------------------------Rachel Hudson Caroline White Carl Watson Laura Barnes Lucy Scott Chris Donaldson Paul Matthews Mark Lawson John Stevens Steven Green Mark Lawson Carl Watson Caroline White Rachel Hudson Laura Barnes Carl Watson Paul Matthews John Scott

18 rows selected. As you can see from Listing 4-16, if brian performs a select count(*) from the table, a result of 2 is returned. If he performs a select count(bugid), a result of 18 is returned. When brian queries the table without referencing the assigned_to column, he can see the data in all the columns he referenced from all 18 rows in the table. However, if the query references the assigned_to column, only the two records assigned to him are returned, as shown in Listing 4-17. Listing 4-17. Referencing the Column in the Query brian@DBTEST> select bugid, reported, assigned_to 2


BUGID ---------2 6

REPORTED --------01-FEB-06 05-FEB-06

ASSIGNED_TO -----------------------------brian brian

At first glance, the difference between the way we used the VPD policy here and what we did earlier may seem quite subtle. Here, users are able to view data from all of the records unless they try to reference the column that is protected by your policy. In other words, any time they try to view data from the protected column, their view of the data is restricted to only those rows that the policy allows. So you can expect this policy to also work just fine from your APEX application. If you run the application as it currently stands, since the report query references the assigned_to column (even though it is not being displayed in the report), the VPD policy restricts the rows to those that are assigned to brian, as shown in Figure 4-26.

173


Figure 4-26. Column-based VPD policy working in the application However, you can change the report query region source so that it no longer selects from the assigned_to column, as shown in Figure 4-27. If you now run the report again, something strange happens: you still get only the same two records returned. This is because, even though you are no longer selecting the assigned_to column in the query, you are referencing the column in the where clause. This illustrates the fact that the policy will be enforced if you reference the column in any part of the statement, even if you are not returning that column in the select statement.

Figure 4-27. Removing the assigned_to column from the select in the report query

174


Once you completely remove the assigned_to column from the report query, all the rows will be returned by the query, as shown in Figure 4-28.

Figure 4-28. Column is not referenced, so all records are returned. As you can see, column-based VPD is an extremely powerful piece of functionality that you can use to further secure data from users. If you need to secure your data like this, using a VPD policy is absolutely one of the best ways to do it, rather than coding the logic inside all your queries (inside all your applications).

Column Masking So, now you can prevent users from seeing data in particular rows if they attempt to query a particular column that is protected by your policy. However, what if you want to allow users to still be able to see all of the rows but prevent them from seeing the data in a particular column? You can do that by using a technique called column masking. Column masking allows you to display all the rows but mask (replace with NULL) the values of the specified columns for the restricted rows. This might sound complicated, but fortunately, it is incredibly simple to implement. First, drop the existing policy:

175


apexdemo@DBTEST> begin 2 3 4 5 6

dbms_rls.drop_policy( object_name => 'buglist', policy_name => 'Buglist Policy'); end; /

PL/SQL procedure successfully completed. Now re-create the policy, as shown in Listing 4-18. Listing 4-18. Re-creating the Policy to Use Column Masking apexdemo@DBTEST> begin 2 dbms_rls.add_policy( 3 object_schema => 'apexdemo', 4 object_name => 'buglist', 5 policy_name => 'Buglist Policy', 6 function_schema => 'apexdemo', 7 policy_function => 'vpd_buglist', 8 statement_types => 'select', 9 sec_relevant_cols => 'assigned_to', 10 sec_relevant_cols_opt => DBMS_RLS.ALL_ROWS); 11* end; PL/SQL procedure successfully completed. Note that, this time, you have included a new parameter, sec_relevant_cols_opt, setting the value to DBMS_RLS.ALL_ROWS, which is a constant defined in the DBMS_RLS package. The inclusion of this new parameter means that you want all of the rows returned from the VPD policy. Now connect to SQL*Plus as the brian user and query the table again, as shown in Listing 4-19. Listing 4-19. Column Masking in Effect with the Policy brian@DBTEST> select bugid, reported, reported_by, assigned_to 2


BUGID REPORTED REPORTED_BY ASSIGNED_TO ------ --------- ----------------- ------------1 27-JAN-06 Rachel Huson 2 02-JAN-06 Caroline White brian 3 01-FEB-06 Carl Watson 4 02-MAR-06 Laura Barnes 5 02-MAR-06 Lucy Scott 6 02-MAY-06 Chris Donaldson 7 02-JUN-06 Paul Mathews 8 02-JUN-06 Mark Lawson 9 02-JUL-06 John Stevens

176


10 11 12 13 14 15 16 17

02-JUL-06 02-AUG-06 02-AUG-06 02-SEP-06 02-SEP-06 02-OCT-06 02-OCT-06 02-NOV-06

Steven Green Mark Lawson Carl Watson Caroline White Rachel Hudson Laura Barnes Carl Watson Paul Mathews

brian

17 rows selected. You can now see all of the rows, but you can’t see the data in the assigned_to column if the record is not assigned to you. This behavior is obviously quite different from what happens when you use column-level VPD, so which one you use will be determined by your requirements. The policy works with your applications. After you modify the report query to again select from the assigned_to column, you can test the results. Figure 4-29 shows the report you will see when logged in as brian.

Figure 4-29. Column masking in the application If you logged in to the application as a different user, you would still be able to see all the rows, but the Assigned To column would show only that data that is assigned to you.

177


As you can see, using VPD column-mask policies is an extremely powerful and flexible way to restrict the access users have to data. This technique might be useful in many different scenarios. For example, you might mask the salary field of an employee report so that employees are able to see only their own salary, while managers can see the salary of everyone who works for them.

A Note About Policy Function Types You may be wondering when the policy function will be evaluated and whether you can control how often the policy function is executed in order to enhance performance. You can define your policy function to be of different types, depending on whether you want the output of your policy function to be cached. You can specify your policy function as one of five different types: STATIC: The policy function is entirely static and will always return the same string. Therefore, the policy function output can be cached and reused repeatedly without having to reexecute the function. SHARED_STATIC: The same as STATIC, but the resulting output can be applied across multiple objects that use the same policy function. CONTEXT_SENSITIVE: This type is used whenever you use an application context. The policy function output can be cached and reused, and the function will be executed again only if the value of the application context is modified. SHARED_CONTEXT_SENSITIVE: The same as CONTEXT_SENSITIVE, except the resulting output can be cached and applied to multiple objects that use the same policy function. DYNAMIC: The policy function is executed every time. This is the default value. If your policy function is likely to be called many times and the output is not likely to change, you may benefit from using one of the other policy types that enables the output to be cached.

 Caution Great care must be taken to use the correct policy type for your policy. For example, using a STATIC policy type could be disastrous for your application security if the policy should actually be evaluated dynamically.

You can define the policy type by using the policy_type parameter when you use the dbms_rls.add_policy procedure, as shown in Listing 4-20. Listing 4-20. Defining the Policy Type apexdemo@DBTEST> begin 2 3 4 5 6 7 8

178

dbms_rls.add_policy( object_schema => 'apexdemo', object_name => 'buglist', policy_name => 'Buglist Policy', function_schema => 'apexdemo', policy_function => 'vpd_buglist', statement_types => 'select',


9 10 11

policy_type => DBMS_RLS.DYNAMIC); end; /

PL/SQL procedure successfully completed.

VPD Best Practices As noted earlier in this chapter, for simplicity, the VPD examples use an approach you will probably not want to take in your own production applications. Let’s look back at a sample policy: apexdemo@DBTEST> begin 2 3 4 5 6 7 8 9 10

dbms_rls.add_policy( object_schema => 'apexdemo', object_name => 'buglist', policy_name => 'Buglist Policy', function_schema => 'apexdemo', policy_function => 'vpd_buglist', statement_types => 'select'); end; /

Notice that the object we were trying to protect (the buglist table) and the policy function that is used to protect it (vpd_buglist) are both contained in the same schema. This presents a potential risk for a production application, especially since the same schema is used as the working schema for the application. If malicious users found a way to run some SQL as the APEXDEMO user (perhaps by using a SQL-injection attack), they might be able to replace your policy function with one of their own, such as one that does not apply any additional predicate logic. They would then be able to gain full access to all the data. To avoid this potential issue, you might wish to create the VPD policy functions in a separate schema entirely, so that one schema is used for your VPD security routines and the other schema is used for your data. You could then lock the account owning the schema in which you created the policy functions, making it much more difficult for malicious users to be able to modify the policy functions in some way.

Auditing Here’s a real-life incident to give you an idea of what can happen without auditing. A user had been training a new employee in how to use the in-house billing system. They had gone through all the different screens, creating new customers and orders, changing entries, deleting entries . . . the whole works. Unfortunately, the user had performed the entire training session while connected to the live system, rather than the test system, and only realized this after a good 30 minutes or so. This led to a frantic call to tech support to ask how to undo the changes they had made. How did this happen? The user had two shortcuts on his desktop, both pointing to the same application but with a parameter in the shortcut determining whether the user connected to the test or live database. Rather than prominently displaying on screen which database the user was connected to, the database connection details were tucked away in a Help About type of pop-up window. On that day, the user accidentally started the application using the wrong shortcut and never thought to check the Help About pop-up window before making all of those database changes.

179


Even worse than not displaying the database connection prominently, the application used a common single account for every user, rather than using separate database accounts for logging in to the database. So, as far as the database was concerned, the same database user was performing all of the changes, since there was no way to tell users apart. This real-life story illustrates two (or rather, at least two!) very important points: •

If you don’t audit the users’ actions, you will not be able to determine what they have done.

•

If you use a common login for all users, you will not be able to track back changes to an individual person, even if you audit every action.

The purpose of this section is to demonstrate how you can very effectively audit the actions of users using your APEX application, as well as anyone accessing the data using another method.

Enabling Auditing The previous sections covered how you can use the DBMS_RLS package to implement VPD policies that restrict the view of data that users will see. You might be thinking you could somehow use this to audit users’ actions, perhaps by performing some logging inside the policy function. Or you might decide to create triggers on the table itself to perform some logging into another table whenever any DML is performed on that table. However, rather than reinventing the wheel, you can use the auditing functionality of the database to do this for you.

 Note The auditing functionality described here assumes you are using the Enterprise Edition of the database. If you are just interested in “who did what,” the Enterprise Edition of the database is not required. It is possible to implement auditing by using triggers or in some other appropriate method, but we recommend using a built-in auditing feature if possible.

You can use the DBMS_FGA package to enable auditing of user actions. The way you use this package is similar to the way you use the DBMS_RLS package. As an example, let’s audit all user actions against the buglist table. To do that, you add a policy (yes, another policy—this time an auditing policy), as shown in Listing 4-21. This needs to be performed by a DBA or another user who has rights to execute the DBMS_FGA package. Listing 4-21. Creating an Audit Policy system@DBTEST> begin 2 3 4 5 6 7 8 9

180

dbms_fga.add_policy( object_schema => 'apexdemo', object_name => 'buglist', policy_name => 'Buglist audit', audit_condition => null, statement_types => 'select,insert,update,delete'); end; /


PL/SQL procedure successfully completed. As you can see, the syntax looks very similar to the syntax you used with the DBMS_RLS package. However, you don’t need to write your own audit procedure, since that is done automatically for you. You have essentially said that you want to audit any select, insert, update, and delete statements against the buglist table in the APEXDEMO schema. One thing that might look a little strange is the audit_condition parameter being set to NULL. You can use the audit_condition parameter to specify a condition restricting the rows to be audited. Setting audit_condition to NULL causes auditing to occur for all rows. If you now query the buglist table as the brian user from a SQL*Plus session, everything appears to work as you would expect: brian@DBTEST> select count(*) from apexdemo.buglist; COUNT(*) ---------2 The user is not made aware that any form of auditing has taken place. However, an audit record has been placed in the audit table.

Viewing Audit Data The audit information is accessible to a DBA via a view called dba_fga_audit_trail: system@DBTEST> select session_id, db_user, object_schema, 2 3

object_name, policy_name from dba_fga_audit_trail;

SESSION_ID DB_USER OBJECT_SCHEMA OBJECT_NAME POLICY_NAME ---------- --------- --------------- --------------- ----------5005 BRIAN APEXDEMO BUGLIST BUGLIST You can tell from the audit log that the user brian accessed the buglist table in the APEXDEMO schema. However, even more information has been captured in the audit table. The definition of dba_fga_audit_trail, shown in Listing 4-22, shows all of the different types of information that is recorded.

181


Listing 4-22. Definition of dba_fga_audit_trail system@DBTEST> desc dba_fga_audit_trail; Name Null? ---------------------- -------SESSION_ID NOT NULL TIMESTAMP DB_USER OS_USER USERHOST CLIENT_ID EXT_NAME OBJECT_SCHEMA OBJECT_NAME POLICY_NAME SCN SQL_TEXT SQL_BIND COMMENT$TEXT STATEMENT_TYPE EXTENDED_TIMESTAMP PROXY_SESSIONID GLOBAL_UID INSTANCE_NUMBER OS_PROCESS TRANSACTIONID STATEMENTID ENTRYID

Type --------NUMBER DATE VARCHAR2(30) VARCHAR2(255) VARCHAR2(128) VARCHAR2(64) VARCHAR2(4000) VARCHAR2(30) VARCHAR2(128) VARCHAR2(30) NUMBER NVARCHAR2(2000) NVARCHAR2(2000) VARCHAR2(4000) VARCHAR2(7) TIMESTAMP(6) WITH TIME ZONE NUMBER VARCHAR2(32) NUMBER VARCHAR2(16) RAW(8) NUMBER NUMBER

You can see from the definition that the actual SQL text that was used should also have been captured, along with the statement type, the value of the system change number (SCN) when the statement occurred, and many other useful pieces of information that would help you to determine the entire environment when the statement occurred. Listing 4-23 shows examples of some of the data you will be able to find logged in the audit table. Listing 4-23. Querying the dba_fga_audit_trail View system@DBTEST> select sql_text from dba_fga_audit_trail; SQL_TEXT -----------------------------------------select count(*) from apexdemo.buglist system@DBTEST> select statement_type, extended_timestamp from dba_fga_audit_trail; STATEME EXTENDED_TIMESTAMP ------- -------------------------------------SELECT 11-NOV-06 06.46.19.196957 PM +00:00

182


system@DBTEST> select db_user, os_user, userhost 2* from dba_fga_audit_trail DB_USER OS_USER USERHOST -------------------- ---------- -------------------BRIAN bhill oim.enkitec.com As you can see, the auditing facility works fantastically well and gives you a lot of information that helps to answer the three big questions: who, what, and when. However, what happens if you access the table via your APEX application? Well, to demonstrate, run the report again, as shown in Figure 4-30.

Figure 4-30. Running the report with auditing enabled Then query the audit table: system@DBTEST> select session_id, db_user, statement_type 2

from dba_fga_audit_trail;

SESSION_ID ---------27020042 24850031

DB_USER -----------------------------BRIAN ANONYMOUS

STATEME ------SELECT SELECT

You can see the issue here: rather than auditing that user brian performed the action in the APEX application, it has been logged as being performed by the ANONYMOUS user. This is because ANONYMOUS is the user specified in the DAD. So, after all we’ve said about not using a single account for logging in to the database, have we reached a roadblock in identifying which user performed the action in the APEX application? Well, as you might have guessed, we wouldn’t have brought you this far if it wasn’t possible to find out which user performed the action. The answer lies in the client_id column. Fortunately, the Oracle team behind APEX had the foresight to populate the client_id for you:

183


system@DBTEST> select db_user, client_id 2

from dba_fga_audit_trail;

DB_USER CLIENT_ID -------------------- -----------------------------BRIAN ANONYMOUS BRIAN:6488441121768716 This is also an extremely good illustration of why it’s important to instrument your code in the same way that the Oracle team has done by including the APEX session information in the client_id column. You never know when that information will be useful to someone else, and if you haven’t made it possible for others to access that information, that lack could cause all sorts of unforeseen problems. The client_id column not only contains the name of the user (brian) but also the session ID that was used (6488441121768716), so the format of the client_id value is user:session_id. Having this level of detail available to you from the audit log allows you to go back into the APEX instance management and drill down into the recent session information that matches the information from the client_id column, as shown in Figure 4-31. Then you can drill down into the session information, as shown in Figure 4-32.

Figure 4-31. Cross-referencing audit information with APEX logs

184


Figure 4-32. Drilling down into the session information

Summary This chapter covered methods you can use to control the data your users can access and what actions they can perform on that data, while auditing the actions they perform. It’s extremely important to consider using features such as VPD and auditing in the early stages of application design. Although you can easily enable functionality such as auditing using the DBMS_FGA package later on, trying to retrofit VPD into an application when you have already written additional predicates for all your queries is a much bigger and more daunting task. There is often resistance to changing things once they are working—after all, who wants to risk being the one to break something that has worked for a long time? This is why you should consider the options you have available to you at the early stages of project design. Investigate the latest database features to see what they can do for you. Many people have written their own auditing solutions when they could have saved a lot of development time by using the built-in database features instead. Take the time to think ahead when you’re designing an application. Think about all the areas in which you can cut down on the amount of repetitive work you need to do. Using packages such as DBMS_RLS and DBMS_FGA means you don’t have to reinvent the wheel to get the job done.

185

CHAPTER 5

Navigation and Layout An often overlooked area of application design is how users will navigate around the system. We typically give a lot of thought to how individual screens and pages will look; but, we don’t always give the same amount of consideration to how the user will move among those pages. Why is this important? Well, if users find it difficult to navigate your application, they will quickly become frustrated with the application. Your application should have a navigation system that’s easy to use and takes into account the areas users will access most frequently APEX provides many components and methods that enable you to create different ways for users to navigate applications. However, there’s no magic formula for determining which method or component will be most suitable for your particular situation—that’s something you’ll need to decide on a case-bycase basis. This chapter covers some of the different tools Apex puts at your disposal for enabling navigation in your application. We’ll concentrate here on using the built-in themes and templates. In Chapter 10, you’ll see how you can modify these—and even create your own themes—to customize your application’s look and feel, as well as its navigation system. It is worth noting that in APEX 4.0, there are even more available themes and new features that can improve the user experience. We’ll explore some of those features in this chapter.

Tabs Tabs are an extremely simple yet efficient way of allowing users to navigate between different pages in your application. They are perhaps among the first navigation aids developers might choose to include, since APEX makes it extremely easy to implement them. You can use two different types of tabs: standard and parent. Standard tabs are for applications that have only one level of tabs, with each tab associated with a particular page (although a tab can also be the current tab for many pages, as you’ll see shortly). A parent tab, in contrast, acts as a container for a group of standard tabs. Using parent tabs, you can group standard tabs under a particular parent tab in order to define a more contextual list of tabs that is specific to the user’s current task. You can access the tabs used in your application in many different ways. For example, each page definition in the Application Builder contains a list of the tabs used on that page in the Shared Components section, as shown in Figure 5-1.

187

CHAPTER 5 ■ NAVIGATION AND LAYOUT

Figure 5-1. Tabs displayed in the Shared Components for the page definition You can also view all of your application’s tabs from the Shared Components section for the application, as shown in Figure 5-2. This screen is actually very comprehensive. It not only shows the tabs you’ve defined for the application, but also displays information about the definition of each individual tab.

188


Figure 5-2. Tabs displayed in the Shared Components for the application

Understanding Tab States: Current and Noncurrent In the example in Figure 5-2, notice that the tab has a single target, represented by the Tab Current for Page attribute—page 1 in this case. In other words, when the users click the tab, they will be taken to page 1. However, the tab can also be “current” for a number of pages, represented by the Tab Also Current for Pages attribute. In Figure 5-2, the tab is considered current for pages 2 through 5. So what does current actually mean? A tab has two states: either current or noncurrent. The difference between current and noncurrent is quite a fluid one, in that you can customize your templates to have your own definitions, as you’ll learn in Chapter 10. However, generally speaking, for the built-in themes and templates, a current tab reflects the fact that the user is currently on a page represented by that tab. In other words, the tab will appear to be different from the other tabs and, again generally, the tab will not be a clickable link. A noncurrent tab reflects the fact that the user can click the tab to navigate to a different page. Current tabs may use different images or colors so users can see at a glance where they are in the application. Exactly how the current and noncurrent states are implemented depends on the way the page template used for the page implements the standard tabs. When users click a tab, they are taken to the page that’s assigned as the current page for that tab (page 1 in the example), and the tab is considered the current tab. However, if the user is on one of the pages 2 through 5, the tab will also be considered the current one.

189


Using Standard Tabs When an application uses a single level of tabs, they are standard tabs. The Buglist application has a standard tab set called TS1, as shown in Figure 5-3, which was created automatically when you created the application. All of the standard tabs belong to this tab set.

Figure 5-3. The standard tab set in the Buglist application Figure 5-3 shows the definition of one of the tabs for the Buglist application. Here, you can define a single page for the page that will be linked to from this tab, as well as multiple entries in the Tab Also Current for Pages attribute, by specifying the individual page numbers separated by commas. You can also place the tab in another tab set, if one exists, by changing the Standard Tab Set attribute. The tab attributes include both Tab Name and Tab Label. The Tab Name attribute is the name you’ll use to refer to the tab within your application. The Tab Label attribute is the text that will appear on the tab when displayed to the user (if you customize the templates, you can display anything you like). You can actually do quite a few interesting things with the Tab Label attribute. The text doesn’t need to be static and hard-coded. You can use substitution values in the Tab Label attribute, which will be replaced dynamically at runtime. For example, rather than setting the Tab Label attribute to Edit Bug, you could use Edit Bug &BUG_NUMBER., which at runtime would show something like “Edit Bug 174,” allowing users to see at a glance which bug they are editing. Figure 5-4 shows some of the other attributes you can define for a particular standard tab. You can specify images to be used for the current and noncurrent states, as well as any additional image attributes. You can also link the tab to a parent tab set and define an authorization scheme for the tab.

190


Figure 5-4. Attributes of a standard tab The Buglist application uses a page template called One Level Tabs. Figure 5-5 shows the definition of the Standard Tabs Attributes section of this template. We’ll cover the details of page templates in Chapter 10; however, from Figure 5-5, you can see that the HTML used for current and noncurrent standard tabs is slightly different—the tabs use different images and different CSS classes for the Tab Label attribute. In this particular page template, the images used for the current and noncurrent tabs are hard-coded. However, if the template for your application uses the #TAB_IMAGE# substitution variable, then the values you entered for the image attributes shown in Figure 5-4 would be applied instead.

Figure 5-5. Page template definition for the standard tab attributes By using authorization schemes with standard tabs, you can control whether a user can access a particular page through a tab. For example, if you implement the business requirement that only

191


administrators should be able to access the Analyze page of your application, you can change the authorization scheme of the Analyze tab to use the USER_IS_ADMIN scheme you created earlier (in Chapter 4), as shown in Figure 5-6.

Figure 5-6. Using an authorization scheme with a standard tab Now if you run the application while logged in as an administrator, you will see the Analyze tab, as shown in Figure 5-7. However, if you are logged in as a nonadministrator, you will not see that tab, as shown in Figure 5-8.

Figure 5-7. An administrator sees both tabs.

Figure 5-8. The Analyze tab is not displayed to nonadministrators.

192


 Note You might have expected to see an error displayed when the nonadministrator logged in, as shown in Figure 5-8. However, in this case, rather than the authorization scheme displaying an error, the tab is simply not displayed to anyone failing the authorization scheme logic, which is preferable behavior for navigation components such as tabs.

As you can see, using authorization schemes with standard tabs is an incredibly powerful way of customizing the navigation of your application dynamically at runtime depending on who is logged in (or any other criteria you prefer). It is also possible to use conditions to determine whether a standard tab should be displayed, which gives even more flexibility to dynamically customize the navigation at runtime. We’ll discuss how to define conditions for navigation in the “Navigation Bars” section later in this chapter.

Using Parent Tabs In order to use parent tabs, you need to use a page template that supports them. Since the Buglist application currently uses One Level Tabs as the page template, you can’t use parent tabs in it. Fortunately, this is quite easy to change. Just edit the page definition and select a page template that supports two levels of tabs, Two Level Tabs, as shown in Figure 5-9. Now if you run the page again, it will look similar to Figure 5-10. Since you haven’t defined a parent tab yet, the tab display is still much like it was before (aesthetics aside).

 Note If you used a different theme, you might see something very different from Figure 5-10, since each theme can display the tab layout in different ways. In fact, themes don’t actually have to support displaying two levels of tabs.

193


Figure 5-9. Changing the Report page to use the Two Level Tabs template

Figure 5-10. The page using the Two Level Tabs page template As an example, let’s create a new parent tab set called Bugtools, under which you’ll group all of the bug-related standard tabs. To begin, click the Add link beside the TS1 tab set, as shown back in Figure 5-2. The link reads “Add,” but if you hover your mouse over the link, the pop-up hint reads “Add New Parent Tab.” This starts the parent tab creation wizard, as shown in Figure 5-11.

194


 Note As with most APEX components, there are many different ways to reach the creation wizard for parent tabs, such as through the page definition or through the Shared Components section for the application. Look around the Application Builder to find all the different ways you can do tasks like this. You’ll probably have a favorite way of doing these things, but it’s always good to be able to find different routes since they might end up saving you more time (and make you more productive!).

Figure 5-11. Creating a parent tab Give the parent tab a label and then assign a target page. You can also assign other attributes that will affect the session state when the user uses the tab, as shown in Figure 5-12.

Figure 5-12. Adding parent tab attributes The attributes you can assign to parent tabs are similar to the usual settings you can make for page branches. You can specify a Request value, which can then be used within processes on the page to determine how the user arrived at that page. You can also clear session state from particular pages and

195


assign values to items held in the session state. For now, simply make the tab take the user to page 1 and don’t do anything with the session state. As you can see from Figure 5-13, the new parent tab you created has now replaced the TS1 tab set. Now suppose you create a new page that displays some helpful information about the application. One of the options during page creation is to define whether a tab or parent tab should be reused or created for that particular page. Figures 5-14 and 5-15 show how parent tabs can help to present different navigation choices to your users depending on which top-level parent tab they select. One tab shows a bug list; the other shows application help.

Figure 5-13. A new parent tab replaces the old TS1 tab set.

Figure 5-14. The Bugtools tab shows a list of tracked bugs.

196


Figure 5-15. The Help tab shows online help. At first, getting parent tabs and two-level tabs working in your application can be quite confusing. Many people find that after they create parent tabs they are unable to get them to display in their application. This is usually because they don’t understand how tab sets, parent tabs, and page templates work. If you are having problems getting your parent tabs to display, check whether you are using the correct parent tab set for that particular standard tab and also whether you have made the tab current for that page. I find it very helpful to open two pages, one running the application and another running the APEX development environment. You can then make changes to the tabs or pages, then switch over to the running application and simply refresh the page to get the new code and test the functionality. Multitab browsers, like FireFox and IE8 make this really easy.

 Note We encourage you to sit down and work through creating some parent tabs. Once you get the hang of this, it really isn’t difficult, although it can seem that way when it is not working how you intended.

Navigation Bars Like tabs, navigation bars can be an easy way to enable user navigation in your application. Unlike with tabs, though, an application may use only a single navigation bar. However, that navigation bar can contain multiple entries that are dynamically enabled and disabled at runtime. If you look at the page template, you’ll see #NAVIGATION_BAR# specified in the Body section (again, this depends on whether the page template and theme you are using support displaying a navigation bar). At runtime, the #NAVIGATION_BAR# is substituted for the actual HTML that represents the individual navigation bar entries.

Accessing Navigation Bar Entries You can access the current navigation bar entries either through the Shared Components section of the application, as shown in Figure 5-16, or through the Navigation Bar section in the page definition.

197


Figure 5-16. Accessing navigation bar entries The Buglist application currently has only a single navigation bar entry defined. This is the Logout entry, which produces the Logout link shown in the top-right corner of the page. Figure 5-17 shows the attributes for this Logout entry. As you can see, you can define an image and a target for the entry. In this case, the entry is using the special URL target of &LOGOUT_URL., which you can define within the authentication scheme for the application. For this application, the following target will be substituted: wwv_flow_custom_auth_std.logout?p_this_flow=&APP_ID.&p_next_flow_page_sess= &APP_ID.:1

198


Figure 5-17. Attributes for the Logout navigation bar entry This means that when the user clicks the Logout link, the standard wwv_flow_custom_auth_std.logout routine will be called, which performs some standard logout logic that you can use in your own applications. The parameters to the URL (which are used as parameters to the procedure) mean that users will be returned to page 1 in the application once they have successfully reauthenticated (remember that page 1 requires authentication). Again, as with tabs, you can also use conditions with navigation bar entries, as shown in Figure 5-18. This example specifies that the navigation bar entry should be displayed only if the user is on page 1 or page 5.

199


Figure 5-18. The conditions for the Logout navigation bar entry Although navigation bar entries don’t have the same capabilities as tabs in terms of being able to define current and noncurrent pages, you can use conditions to effectively mimic the same sort of behavior. For example, you can use the current page number or some other criteria to display different navigation bar entries.

Creating Navigation Bar Entries Let’s create a couple of new navigation bar entries: a simple Home entry to take users back to the first page of the application and a Help entry to open a pop-up Help window. Notice that when you create a navigation bar entry from scratch, you are asked whether this will navigate to a standard URL or to a Feedback page. As described in Chapter 1, Feedback pages are used to gather comments from users. For this exercise, we will use the URL method. Create the Home entry as shown in Figure 5-19. To keep the example simple, just use a text link. However, you could quite easily use an image as well as or instead of the text. Add a simple condition, as shown in Figure 5-20, saying that the entry will not be displayed if users are already on the home page. Also, rather than using a URL target type, use a page in the application as the target, as shown in Figure 5-21.

Figure 5-19. Creating the Home navigation bar entry

200


Figure 5-20. Using a condition with the Home navigation bar entry

Figure 5-21. Specifying the page target for the Home navigation bar entry If you run the page again, you’ll see the new navigation bar entry displayed in the top-right corner, alongside the Logout link, as shown in Figure 5-22 (but remember that you won’t see the new entry if you are already on page 1). Notice that the new Home link appears before the Logout link. That’s because the Sequence attribute for the Home link is a numeric value that’s less than the Sequence attribute value for the Logout link. The navigation bar entries are output in ascending order, so you can use the Sequence attribute to maintain a particular order among your entries.

201


Figure 5-22. The new Home navigation bar entry is displayed next to the Logout link. Now let’s create the Help entry. This time, use a URL target, as shown in Figure 5-23. The URL target uses the following value: javascript:popUp2('f?p=&APP_ID.:HELP:&SESSION.', 400, 400); The popUp2 JavaScript routine is one that is defined in the standard APEX JavaScript libraries, so you can use it in your own applications. The first parameter to the procedure is the URL you wish to open. Here, you’re passing in the standard APEX URL f?p as well as some parameters to it that will take you to the Help page in the same application (note that here you’re using the page alias HELP, rather than passing in a numeric page ID). The second and third parameters to the JavaScript routine are the width and the height of the pop-up window.

202


Figure 5-23. Creating the Help navigation bar entry If you now rerun the page and click the Help link, you should see something similar to Figure 5-24. Note that the pop-up window is actually displaying the Help page as it would appear if you had navigated to it using the tabs; that is, you now have a pop-up window that also contains tabs and navigation bar entries. In a production application, most likely you wouldn’t want to do this. Instead, you could define a very minimal page template specifically for your pop-up windows and use that. However, this example does demonstrate that you can easily add the ability to create a pop-up window from your navigation bar.

203


Figure 5-24. Displaying the pop-up Help window

Performing an Action on the Current Page In some cases, you might want your navigation bar entry to take you back to perform an action on the current page. For example, you might want an entry to print the current page, to make the current page printer-friendly, or to reset the pagination on the current page. In this case, rather than hard-coding the page ID, you can use the substitution variable &APP_PAGE_ID., which will be replaced by the current page ID when you run the application. This way, the same navigation bar entry is able to work on multiple pages. Figure 5-25 shows how to use &APP_PAGE_ID. to create a navigation bar entry that will put each page into Printer Friendly mode. Here, the page target specified is the &APP_PAGE_ID. substitution variable, and the Printer Friendly check box is selected. If you now run the application and click the Printer Friendly navigation bar entry, you will see a screen similar to Figure 5-26.

 Note Make sure you add the period “.” after the name of the &APP_PAGE_ID or you will get a nasty browser error that does not identify the root cause of the problem. You will not be able to see the entire substitution variable in the properties panel.

204


Figure 5-25. Using the &APP_PAGE_ID. substitution variable to put the page in Printer Friendly mode

Figure 5-26. A page in Printer Friendly mode Note that there is no magic behind Printer Friendly mode. All it does is to make the page use a specific page template in which you can alter the layout of the page to be more suitable for printing. In this example, the template removed the navigation bars as well as the tabs and some of the form fields. You can completely customize the Printer Friendly template if you wish.

205


 Tip Navigation bars may not suit all types of applications, but they do offer a very simple and quick way of defining a navigation system for your application. You may want to use navigation bars during the prototype phase of your application, while you’re toying with different ideas for screen layouts.

Breadcrumbs Breadcrumbs are yet another tool you can use to help users navigate your application. However, unlike most of the other navigation tools, breadcrumbs have a quite unique characteristic: they allow users to easily see their current position in the application relative to other areas of the application. Users can go back to previous locations in the application by following the breadcrumb trail created by their actions. The Buglist application already has a breadcrumb menu, displayed just below the tabs, as shown in Figure 5-27. In this figure, the breadcrumb trail says the user is currently on the Analyze page and got to that page via the home page. Actually, the last part of the preceding sentence may or may not be true, since breadcrumbs allow for a great deal of flexibility in how you associate breadcrumb entries with each other. The way to read the breadcrumb trail in this case is that the user is able to go directly to the home page by clicking the Home link in the breadcrumb trail.

Figure 5-27. The breadcrumb trail shows the user is on the Analyze page. An application can have multiple breadcrumbs defined and can display multiple breadcrumbs simultaneously. However, we suggest you use only one breadcrumb menu, perhaps two if necessary. Displaying more than two menus is rarely helpful and can actually make the task of navigating more confusing.

Accessing Breadcrumb Entries You can view the breadcrumbs for your application from the Shared Components section, as shown in Figure 5-28, or via the page definition. If you select the Buglist breadcrumb, you also get a very useful outline of the breadcrumb entries, as shown in Figure 5-29.

206


Figure 5-28. Breadcrumb defined for the application

Figure 5-29. Breadcrumb entries defined for the Buglist breadcrumb This outline view of the breadcrumb entries makes it easy to see how each breadcrumb entry relates to every other breadcrumb. For example, you can see that the root entry is Home, with four entries below it: Analyze, Insert Bug, Update Bug, and Success. The Analyze entry also contains a number of entries below it. You can also see that each breadcrumb entry corresponds to a particular page. This is

207


similar to the way that tabs can be tied to a particular page; however, unlike a tab, a breadcrumb can relate to only an individual page. Figure 5-30 shows some of the interesting attributes you can define for a breadcrumb entry: Page: Specifies where the breadcrumb entry will appear. You can see that the Analyze breadcrumb entry is assigned to page 5, which means that the breadcrumb entry will be shown if you are on page 5. Short Name and Long Name: Specifying a short name for the breadcrumb entry is mandatory. Optionally, you can also enter a long name. Depending on the theme and page template you use, the breadcrumb menu might use either the short name or the long name. Parent Entry: Defines the parent breadcrumb entry that will appear with this breadcrumb entry. The parent for the Analyze breadcrumb is the Home breadcrumb, so if you are on page 5, you will see not only the Analyze breadcrumb, but also the Home breadcrumb. Similarly, if you have any other breadcrumbs that use the Analyze breadcrumb as their parent, the Analyze breadcrumb will also be displayed when you are on any of those pages. As mentioned earlier, the Home breadcrumb entry is the root entry, because it doesn’t have a parent entry defined. There can be only one root breadcrumb entry in your breadcrumb trail. Target: Assigns a target for the breadcrumb entry. In this case, the target is also page 5, so clicking the breadcrumb entry will take you to page 5. (Remember that the breadcrumb entry can also be displayed when the user is on a page other than page 5 if that page uses a breadcrumb that is a descendant of this breadcrumb.) You can also choose a page target different from the page used in the Breadcrumb section. Bear in mind that this may be confusing to users, since the page they branched to would not be the same as the page the breadcrumb links to; however, there may be cases where this is the behavior you want.

208


Figure 5-30. Breadcrumb entry attributes

209


Using Dynamic Breadcrumb Entries As with some of the other navigation tools, you can use substitution variables with breadcrumb entries to enable them to display dynamic information at runtime. For example, if you want to modify the Update Bug breadcrumb entry to also display the number of the bug that is currently being edited, you could include the substitution variable P3_ID in the Short Name attribute for the breadcrumb, since this is the page item that represents the ID of the current bug, as shown in Figure 5-31. Then, when you edit a bug, the breadcrumb entry will also contain the bug ID, as shown in Figure 5-32. This is a bit of a contrived example, since the bug ID might not be that useful in the breadcrumb entry. However, sometimes including dynamic information in the breadcrumb entry is a good idea. For example, imagine you are drilling down into a report of employees belonging to different departments. Once you select a department, you could filter the list of employees to show only those belonging to that particular department. You could show the department in the breadcrumb entry, so that users can easily see which department they are currently viewing.

 Note Using substitution variables is not just limited to breadcrumb entries. You can use this technique in many different places to make your user interface much more dynamic and reflect at runtime what your users are actually doing.

Figure 5-31. Using a substitution variable in the breadcrumb entry

210


Figure 5-32. The breadcrumb entry now displays the bug ID.

Displaying Breadcrumbs To display your breadcrumb menu on a page, you must create a Breadcrumb region on that page, as shown in Figure 5-33. You can then select which breadcrumb menu you wish to use, as shown in Figure 5-34. The wizard allows you to create a new breadcrumb entry for the page and specify which breadcrumb entry should be the parent for the new entry, as shown in Figure 5-35. Figure 5-36 shows the page running after the new breadcrumb has been added.

211


Figure 5-33. Adding a Breadcrumb region to the Help page

Figure 5-34. Selecting the breadcrumb to use in the region

212


Figure 5-35. Defining the parent breadcrumb entry

Figure 5-36. New Breadcrumb region displayed on the page You might be thinking that having to create a Breadcrumb region on each page is quite repetitive work and surely there must be an easier way to do it. You’re absolutely right. An easier way to do it is by using page zero. As mentioned in Chapter 1, page zero is useful for displaying the same page element on all or multiple pages of your application; it’s discussed in more detail later in this chapter.

Lists Lists are another tool you can use to create a navigation aid in your application. Lists share many of the features of tabs, navigation bars, and breadcrumbs. They are extremely versatile—perhaps even more so than some of the other navigation tools. Lists offer simplicity and ease of use, and you can use them to create many different types of navigation interfaces—with amazing results. Some great user interfaces are created using nothing more than some CSS and a list (for example, the APEX Evangelists site at http://apex-evangelists.com and the DG Tournament site at /www.dgtournament.com), so don’t underestimate them. In fact, some developers opt to use a list where others would choose tabs.

Accessing List Entries The Buglist application already contains a couple of lists, created automatically by the application creation wizard. The lists are visible on the Analyze page, as shown in Figure 5-37. One list shows the

213


links for the reports, and the other displays the links available for charts. At first glance, the lists don’t appear particularly exciting. In fact, they look like links, similar to the navigation bar entries.

Figure 5-37. Lists as a navigation aid The Lists section of the Shared Components shows the two lists that were created, as shown in Figure 5-38. If you examine the Charts list, you can see the individual list items, as shown in Figure 5-39. The list entries look similar to the entries you can have in standard tabs or the navigation bar. You can give each list entry a target (where clicking the list entry will take the user), as well as define a condition for each. It’s only when you view the individual attributes for a list entry that you can see the full range of available settings, as shown in Figures 5-40 and 5-41.

Figure 5-38. Lists available as shared components for the application

214


Figure 5-39. List entries in the Charts list

Figure 5-40. List entry attributes

215


Figure 5-41. More list entry attributes In a way, lists combine the simplicity of navigation bar entries with the complexity of tabs. You can see from Figure 5-40 that you can build a hierarchy of list entries, with one entry being the parent of another. You can also define a target page for the list entry, as well as define the list of pages for which this list entry should be regarded as current, in much the same way as with tabs. Currently, none of the Charts list entries has a parent defined, which is why they all appear at the same level in the list. You can easily change the parent entry for some of the entries, as shown in Figure 5-42. Here, the By Reported list entry is the parent of the By Status and By Report By list entries. However, if you ran the application again, you would not see any difference in the way the list entries are displayed on screen. This is because the template that is currently being used for the list does not take the hierarchy into account.

Figure 5-42. List with an implied hierarchy To show the hierarchy, you need to change the template from Vertical Unordered List without Bullet to another template, such as DHTML Tree, as shown in Figure 5-43. Now if you run the page, you should see the output shown in Figure 5-44. In this figure, we’ve expanded the list by clicking the plus sign (+) next to By Reported, which reveals the two items under it.

Figure 5-43. Changing the list template

216


Figure 5-44. The list is now displayed in a hierarchical manner. You can use other built-in templates to change the appearance of the list. By simply changing the template, you can change the list from being a vertical list to a horizontal list. You can also define images used with each list entry, or you could go for a completely DHTML menu. In fact, with APEX, you can have total control over the look of the list, since you can define your own list template. That way, you can create pretty much any sort of layout that is possible with HTML, CSS, and JavaScript.

Creating a Menu Using a List So, how can you create a menu for your application using a list? You can do this by using the same principles as the two lists that were automatically created: add a new list and then create new list entries that link to particular pages. You can then display that list on each page, which will enable users to navigate to different pages. Figure 5-45 shows the first step of creating a new list, using the Vertical Sidebar List template. (You can always change the list template later.) Next, create some simple list entry items for the list, as shown in Figure 5-46. These entries have been linked to the same pages you’d be able to navigate to using the tabs or links in the application.

Figure 5-45. Creating a new list to use as a menu

217


Figure 5-46. Adding list entries Now you need to display the list on the page, so create a new region on the home page as shown in Figure 5-47. This example uses the Sidebar Region for the template and also positions the display point of the region on the right side of the screen. The template for this region has been changed to Tree List (note that the template used for the region and the template used for the list are different types). If you now run the application and look at the home page, you’ll see the list menu, as shown in Figure 5-48.

 Note You’d probably expect a navigation menu to appear on the left side of the screen (well, people who read from left to right would expect that). However, in the page template used in this example, there is no suitable position on the left side. As you’ll see in Chapter 10, you can modify the page template to position items wherever you desire.

Figure 5-47. Creating a new list region on the home page

218


Figure 5-48. Displaying the navigation list Clicking a list entry will take you to the relevant page. However, the menu is displayed only on the home page at the moment; if you click a link that takes you to another page, you won’t be able to access the navigation list from there. As with breadcrumbs, you need to create a region on each individual page to display the list. And again, you can use page zero to achieve that in an efficient way. As with tabs, you can also incorporate authorization schemes with individual list entries. For example, if you want to make sure that only administrators can access the Assigned To list entry, select the USER_IS_ADMIN authorization scheme you created in Chapter 4, as shown in Figure 5-49. If you now log in as a nonadministrator (using the jimb user, for example) and access the home page, you will no longer see the Assigned To list entry, as shown in Figure 5-50.

Figure 5-49. Adding an authorization scheme to a list item

Figure 5-50. Nonadministrators will not see the Assigned To entry.

219


Notice that the hierarchy of the list items is still preserved, even though one of the items is no longer visible. You might be wondering what would happen if you applied the same authorization scheme check to the Analyze entry. As you can see in Figure 5-51, in that case, not only is the Analysis entry not visible, but you also can’t see any entries that have the Analysis entry as their parent (and so on down the hierarchy chain).

Figure 5-51. Child entries are also hidden by authorization schemes. So, even though you haven’t applied the authorization check to the Reported By list entry, the fact that you applied the authorization check to the parent item means that unauthorized users can’t see any children of that parent item. This is an extremely powerful way of controlling access to a hierarchy.

Tracking Clicks on List Entries Lists have a couple of features that can be extremely useful in certain circumstances. One is the ability to automatically count the number of times a user selects a particular list entry. Through the attributes of each individual list entry, you can specify whether clicks on that entry should be counted, as well as a category for that click. By using categories, you can group different list entries for statistical purposes. For example, rather than counting individual clicks to both the By Reported By and By Assigned To entries, you might group both entries into an Analysis category. You might also enable the Home list entry for click counting and assign it a category of Home, as shown in Figure 5-52.

Figure 5-52. Counting list entry clicks The clicks are counted internally through the APEX_UTIL.COUNT_CLICK procedure (or the shorthand notation Z), which will automatically log the clicks so you can view the results in the Administration section of your workspace. In the example in Figure 5-53, you can see that user jimb clicked two list items, both in the Home category (actually, he clicked the Home entry twice).

220


 Note The click log isn’t very detailed. For example, you can’t see where the user was connecting from (his remote IP address) or what type of web browser he used. However, for simple logging purposes, the click log is definitely worth using.

Figure 5-53. Viewing external clicks in the Workspace Administration section You can use this functionality when you want to keep a simple record of how your users navigate through your system. It can be very useful to know which areas of your application are the least or most used. Based on this information, you may want to adapt your application’s design so that the most commonly used parts of the application are easy to access.

Using User-Defined Attributes for List Entries So, what other tricks can you do with lists? The answer lies in the rather vaguely named User Defined Attributes section of the list entry, as shown in Figure 5-54.

Figure 5-54. The first three of the ten user-defined attributes you can add to a list item What are these attributes for? As the name implies, they’re for anything you would like. The key is understanding how the list template works. For example, the definition for the Tree List template shows

221


that the same HTML is used to represent the list items, regardless of whether they are considered current, as shown in Figure 5-55. Suppose you want to change the way each entry is displayed by wrapping each one in an HTML DIV section and using some CSS to specify what each DIV section should look like. The problem here is that using the standard attributes, you can differentiate between only a current and noncurrent entry, not between the different entries themselves. However, by using the user-defined attributes, you can change the look of individual entries. First, modify the HTML in the Template Definition section to wrap the entry in a DIV section:
#TEXT#
The substitution variable #A01# corresponds to the first user-defined attribute. Similarly, #A02# corresponds to the second user-defined attribute, #A03# to the third, and so on.

Figure 5-55. Definition of the Tree List template Next, specify a value for the first user-defined attribute for the Home list entry, as shown in Figure 5-56.

222


Figure 5-56. Specifying a user-defined attribute If you now run the application and view the HTML source code for the home page (you can usually do this via the View menu in your browser or by right-clicking the page and choosing View Source), you should see that the HTML generated for the Home list entry looks like this (with the code between the anchor tags omitted for brevity):
You can see that the DIV ID contains the substitution value that was specified in the User Defined Attributes section for the Home entry. Now you can implement your own CSS and then style each list entry in whatever way you desired.

Trees Trees are typically used where you wish to represent hierarchical information. As you saw in the previous sections, you can create a menu system with a hierarchy, so you should be able to use a tree to display it. So how would you go about creating a menu framework using a tree? As an example, let’s mimic the menu created earlier using lists, this time using a table to specify the entries.

Creating a Table for the Tree Entries First, create a simple table to hold the list of entries, as shown in Listing 5-1. Listing 5-1. Creating a Table to Store the Tree Entries apexdemo@DBTEST> create table tree_navigation( 2 3 4 5

id number, parent_id number, title varchar2(30), link varchar2(60));

Table created. The table is very simple, containing only four columns: •

The id column will contain a unique identifier for the entry.

•

The parent_id column will refer to the ID of another entry if this entry has a parent. If parent_id is null, that entry will be considered to be the root node for the tree. There can be only a single root node.

•

The title column will be the text displayed in the tree.

223


•

The link column will enable you to direct users to another location if they click a particular tree node.

Next, insert some records that will mimic the same hierarchy used with the list earlier, as shown in Listing 5-2. Listing 5-2. Creating Data for the Tree Layout apexdemo@DBTEST> insert into tree_navigation 2 3

values (1, null, 'Home', 'f?p=&APP_ID.:1:&SESSION.');

1 row created. apexdemo@DBTEST> insert into tree_navigation 2 values 3 (2, 1, 'Analysis', 'f?p=&APP_ID.:5:&SESSION.'); 1 row created. apexdemo@DBTEST> insert into tree_navigation 2 values 3 (3, 2, 'Assigned To', 'f?p=&APP_ID.:13:&SESSION.'); 1 row created. apexdemo@DBTEST> insert into tree_navigation 2 values 3 (4, 2, 'Reported By', 'f?p=&APP_ID.:10:&SESSION.'); 1 row created. apexdemo@DBTEST> commit; Commit complete. apexdemo@DBTEST> select * from tree_navigation; ID PARENT_ID TITLE --- ---------- ------------1 Home 2 1 Analysis 3 2 Assigned To 4 2 Reported By

LINK -----------------------------f?p=&APP_ID.:1:&SESSION. f?p=&APP_ID.:5:&SESSION. f?p=&APP_ID.:13:&SESSION. f?p=&APP_ID.:10:&SESSION.

Notice that the records use a link in the format of f?p, which allows you to refer to another page in the application. The benefit of doing it this way is that you can also specify links external to the application by using a fully qualified URL, such as http://www.google.com.

224


 Note This is a simple example for demonstration purposes. In practice, you’d probably want to use a sequence for the ID column, rather than manually inserting a value. Also, you’d need to ensure that there was only one entry in the table with a parent_id of null; that is, only one root node should be allowed. And, of course, in your production system, you would want to investigate some suitable indexes for a table like this!

Creating the Tree Component Now you can create the tree component, as shown in Figure 5-57. By default, the tree creation wizard will create the tree on a new page. If you wish to place the tree on an existing page, change the Page Number attribute to the page you wish to use.

Figure 5-57. Creating a tree APEX 4.0 lets you choose from three basic tree templates as shown in Figure 5-58. Choose the Classic style for this example.

225


Figure 5-58. Selecting the tree template You can choose to base the root node of your tree on a pop-up LOV, a SQL query, or a static item. Since this example stores the root node in the same table as the rest of the tree entries, choose to base it on a SQL query, as shown in Figure 5-59. The query for the root node is very simple: select id from tree_navigation where parent_id is null You could use some other criteria in your own applications, such as always giving the root node an ID of zero. However, in this example, the root node will have a null parent_id, so this simple query will work. The wizard will then ask which schema and table should be used to create the tree. You will also need to specify which columns in that table to use, as shown in Figure 5-59. Also, as shown in the figure, choose to make the leaf node text a link by setting the Link Option attribute to Existing Application Item. This allows you to use the link column in the table.

226


Figure 5-59. Selecting the tree attributes

If you now run the application, you should see a new Tree region on the page, as shown in Figure 5-60. If users click any of the tree entries, they will be taken to the page specified in the link column of the table.

Figure 5-60. Tree region being driven from the table

Enabling and Disabling Tree Entries You can extend this example to add the ability to enable and disable tree entries. As shown in Listing 5-3, add an enabled column to the table and update the Assigned To entry to be disabled.

227


Listing 5-3. Adding an Enabled Column to the Table apexdemo@DBTEST> alter table tree_navigation 2

add (enabled char(1) default 'Y');

Table altered. apexdemo@DBTEST> update tree_navigation 2 set enabled = 'N' where id = 3; 1 row updated. apexdemo@DBTEST> commit; Commit complete. apexdemo@DBTEST> select * from tree_navigation; ID PARENT_ID TITLE --- ---------- ------------1 Home 2 1 Analysis 3 2 Assigned To 4 2 Reported By

LINK -----------------------------f?p=&APP_ID.:1:&SESSION. f?p=&APP_ID.:5:&SESSION. f?p=&APP_ID.:13:&SESSION. f?p=&APP_ID.:10:&SESSION.

ENABLED ------Y Y N Y

Now modify the tree query to use the new enabled column, as shown in Listing 5-4. Listing 5-4. Adding a Restriction to the Tree Query select "ID" id, "PARENT_ID" pid, "TITLE" name, "LINK" link, null a1, null a2 from "#OWNER#"."TREE_NAVIGATION"

If you run the application again, you will see that the Assigned To entry is no longer displayed in the tree, as shown in Figure 5-61. As with a list menu, if you disable an entry that also contains child nodes (for example, the Analysis entry), the child nodes will also be disabled. That means you won’t see any child nodes that descend from the disabled node, even if those child nodes are not disabled themselves.

228


Figure 5-61. Disabled entries do not appear in the tree.

 Tip For another example of what you can do with trees, see Tony Jedlinski’s excellent article “Build a Menu Framework.” This article was published in the May/June 2006 edition of Oracle Magazine and is also available online (currently at www.oracle.com/technetwork/issue-archive/2006/06-may/o36apex-086847.html).

Page Zero How does page zero relate to navigation? As you’ve learned in this chapter, breadcrumbs and lists (and trees, too) need to be created in a region on each page you wish to use them. Page zero is the solution to all that repetitive work. You can think of page zero as a page with a very special purpose: to define elements that can appear on multiple pages within your application. In other words, if you define a region on page zero, that region can automatically appear on page 10 or page 15, even though you didn’t specifically define the region on those pages. The previous sentence says “can appear” rather than “will appear,” because you have complete control (through the use of conditional logic) over which pages anything you define on page zero will affect. As an example, let’s use page zero to make the navigation list you created earlier appear on every page, rather than just the home page.

Creating Page Zero The first step is to create a page zero, since it isn’t automatically created for you in your application. The page creation wizard includes a Page Zero option, as shown in Figure 5-62.

229


Figure 5-62. The Page Zero option appears at the bottom of the page creation wizard’s choices for page type. Once the wizard has completed, you should see your new page zero, as shown in Figure 5-63. As you can see, in the Application Builder, page zero looks quite different from other pages. Also, notice that it is not possible to run page zero directly.

230


Figure 5-63. Page zero added to an application

Adding Regions to Page Zero You can now create a new List region on page zero, as you did earlier for the home page, and use it for the navigation list you created in the previous section. If you run the application again, you’ll see that the home page now contains two list menus, as shown in Figure 5-64.

Figure 5-64. A List region defined on page zero appears on the Home page.

231


One of the lists is due to the region defined on page zero, and the other list is due to the region defined on the home page. If you click the Analysis link in either list, you will see that the list defined on page zero also appears on the Analysis page, as shown in Figure 5-65.

Figure 5-65. A List region defined on page zero shows on every page. The benefits of using page zero should now be obvious. By defining a single region on page zero, you can display the same navigation menu on every page of your application. This means that you have drastically reduced the number of bits of code you need to maintain. For example, if you want to move the list from the right side of the screen to the left, you need do that in only a single place, on page zero. If you had defined the menu individually on each page, you would need to change it in every individual place. Centralizing the code makes it far easier to adapt your application, and it also removes the possibility of forgetting to make a change somewhere. But what if you want the menu to appear on only certain pages, rather than on every page? Well, once again, that’s incredibly easy to do. You just use a condition in the region on page zero. Figure 5-66 shows using the “Current Page Is Contained Within Expression 1 (comma delimited list of pages)” condition to specify the list of pages on which the region should be displayed.

Figure 5-66. Using a condition to specify certain pages Remember that you are limited only by your imagination here. You don’t have to base the display on particular pages. Here are a few other possibilities:

232

•

The condition could check the value of an application item.

•

The condition could be based on the currently logged-in user.


•

The condition could check the current time (imagine a system that displays a certain menu only during “out-of-office-hours” time).

•

You could use some PL/SQL that queries a remote web server to determine if the menu should be shown.

Conditions allow amazing levels of control over your application. You can build some incredibly dynamic applications by using conditions within your navigational aids.

Layout The built-in themes and templates allow you to position regions and page items in particular locations on the screen. Remember that you can create your own themes and templates, which allows you complete freedom to position your regions and items anywhere you desire. We will cover creating your own themes and templates in Chapter 10. Here, we’ll concentrate on the mechanics of using the built-in ones.

Positioning Regions Whenever you create a region on a page, you need to specify where you want the region to be positioned. In the Application Builder, you will see a drop-down list of all the currently available display points, as shown in Figure 5-67. These display points are defined in the current page template for the page.

Figure 5-67. List of currently available display points If you look at the page template (accessed from the Templates section of the Page Definition page of the Application Builder or from the Shared Components section, which shows all the templates), you’ll

233


see a lot of HTML in different sections, which is used to generate the page at runtime. For example, the HTML for the Footer section of the Two Level Tabs page template is shown in Figure 5-68. Notice the substitution variable called #REGION_POSITION_05#. This corresponds to the Page Template Region Position 5 option in the Display Point drop-down list. The HTML used for the Body section of the page template contains other substitution variables, which correspond to the other available display points. The positions of these substitution variables in the page template determine exactly where the display points that you use for your regions will appear at runtime.

Figure 5-68. Footer section for a page template Note that multiple regions can be contained in the same display point. In other words, you don’t need to put each region into a different display point. The display point is effectively a container for your page regions, in the same way that the page itself is a container for different display points. Fortunately, you don’t need to keep checking the page template to see where each display point will end up being positioned. APEX makes it extremely easy to see how the display points will be displayed at runtime. Just click the small flashlight icon next to the Display Point drop-down list to see a pop-up window that shows a visual representation of the layout of the current page, as shown in Figure 5-69. For example, earlier in the chapter, you positioned the list menu in Region Position 3. From the pop-up layout window, you can see that Region Position 3 is on the right side of the screen.

234


Figure 5-69. Pop-up display of the page layout This pop-up representation of the page layout is completely dynamic. If you change the page template to move the region positions around, the pop-up will reflect the changed positions. The position of these regions is entirely dependent on the page template (and therefore dependent on the theme you are using). If you change the theme (or template) the application is using, you may find your page regions appear in different positions. This gives you an extremely powerful way of completely changing the look and feel of your application, without having to manually reposition the page regions. However, there may be cases where you are using a display point in one page template (for example, #REGION_POSITION_05#) that does not appear in another page template, since not all the region positions must be specified in a template. In this situation, you would need to choose another display point for your page region from the ones that are available in the new template. Since you can have multiple page regions within the same display point, the order in which those page regions appear on the page is determined from the Sequence attribute value that you specified for each region, as shown in Figure 5-70.

235


Figure 5-70. Sequence attribute for a page region The example shows a Sequence attribute of 40, which means that the region would be rendered after any regions that have a Sequence attribute lower than 40, but before any regions that have a Sequence attribute greater than 40. This makes it very easy to change the order of your regions within the display point simply by changing the Sequence attribute. Also notice in Figure 5-70 the attribute named Column. This is used where you want to display multiple regions at the same horizontal position in the same display point. So, for example, if you modify the list that is defined on page 1 to use column 2 (remembering that the list defined on page zero is using column 1), you will see the two lists displayed horizontally next to each other, as shown in Figure 5-71.

Figure 5-71. Lists displayed in columns To implement the Column attribute, behind the scenes, APEX creates an HTML table for your regions and uses the Column value to position the region within that particular column. By using the Sequence and Column values, you can position multiple regions within the same display points in whatever vertical and/or horizontal arrangement you wish.

Positioning Page Items Page items are positioned within page regions (buttons can be placed in a particular page region position or among the region items, for example), in much the same way that you position page regions within pages. Figure 5-72 shows the page items defined on the Update Bug screen.

236


Figure 5-72. Page items displayed in order of sequence In Figure 5-72, the sequence value of each item is displayed just to the left of the item name; for example, the P3_DESCRIPTION item has sequence 6. You can see that the page items use the sequence value to determine their order within the region. You can also specify whether the page item should begin on a new line and field, as shown in Figure 5-73. The values that you select for these two attributes will determine how APEX displays the page item on the screen. Like the Column attribute for page regions, the Begin on New Line and Field attributes are used when APEX builds an HTML table to display the page items. If you select Yes for Begin on New Line, APEX will begin a new table row for your page item; otherwise, the item will be displayed horizontally after the previous page item. If you select Yes for the Field attribute, APEX will generate an HTML td tag (a new table column) in which to display your page item; otherwise, the page item will be displayed inside the same table column as the previous page item. Note that only certain combinations of Begin On New Line and Field are allowed: Yes/Yes, No/No, and No/Yes. You can’t choose to begin on a new line without also creating a new field.

Figure 5-73. Display attributes for a page item

237


Drag-and-Drop Positioning APEX 3.0 introduced drop-and-drop positioning for page items. This is a very slick and cool way to arrange your page items without needing to manually alter the sequence values and layout attributes. To access the Drag and Drop Layout screen, click the small rectangular icon next to the up and down arrows in the Items section of your page. In Figure 5-72, you can see the icon just above the words “Number Field” to the right of P3_BUGID. A very useful feature is hiding behind this innocuous-looking icon. Figure 5-74 shows the Drag and Drop Layout screen. All of the page items you have on your page will appear here. On this screen, you can drag the individual page items around and place them in new positions on the screen. You can also drag new page items onto the page and place them where you want them to appear. And you can remove page items by dragging and dropping them into the recycle bin at the bottom of the page.

Figure 5-74. Drag and Drop Layout screen (some page items omitted for brevity) This is a great new feature of APEX. It makes laying out your screen much easier, since you can see how it will look without having to run the application. Currently, drag-and-drop layout works on a perregion basis. A future release may extend this functionality to allow regions to be moved around using the same drag-and-drop method.

238


Summary APEX supports several approaches to menus and layout. Tabs are commonly used on web pages, often to denote major sections within a site. APEX easily supports tabs. APEX also gives you the ability to create navigation bars for more detailed and granular navigation through a site. You can create navigation bar menus based on lists and trees that allow users to quickly navigate to specific pages. Breadcrumbs let you track a user’s path through your site. Page zero and other layout-related features help you create and maintain a consistent look across all of your site’s pages.

239

CHAPTER 6

Reports and Charts Many applications need the ability to display information to the end user in the form of a report or a chart. Fortunately, APEX makes this extremely easy, allowing you to create reports and charts out of the box. APEX provides an assortment of ready-made report and chart types, and you can customize them in many ways. APEX 4 includes a new charting engine, AnyCharts 5.1, which improves rendering time, generates better graphics, and allows for greater customization.

Reports You might think of reports as a simple way to present record information in a tabular format. You would certainly be correct, but reports are much more flexible than that. In APEX, you have complete control over how a report is processed and presented, which means that you can create some really advanced reports. Looking at the home page of the Buglist application, you can see the report that was automatically created by the application creation wizard, as shown in Figure 6-1. This report has the same look and feel as the rest of our application because it is using a particular template. We will cover how to customize templates in general in Chapter 10. In this chapter, we will look at how you can modify the layout and look of reports specifically.

241

CHAPTER 6 ■ REPORTS AND CHARTS

Figure 6-1. Buglist report The code used as the region source for the report is quite a simple query, as shown in Listing 6-1. Listing 6-1. Buglist Report Region Source Query select "ID", "BUGID", "REPORTED","STATUS", "PRIORITY","DESCRIPTION", "REPORTED_BY", "ASSIGNED_TO" from "BUGLIST" where ( instr(upper("STATUS"),upper(nvl(:P1_REPORT_SEARCH,"STATUS"))) > 0 or instr(upper("PRIORITY"),upper(nvl(:P1_REPORT_SEARCH,"PRIORITY"))) > 0 or instr(upper("DESCRIPTION"),upper(nvl(:P1_REPORT_SEARCH,"DESCRIPTION"))) > 0 instr(upper("REPORTED_BY"),upper(nvl(:P1_REPORT_SEARCH,"REPORTED_BY"))) > 0 )

or

The code in Listing 6-1 was generated automatically by the application creation wizard. Note that the query uses quotation marks (quotes) around the column names and the table name. Generally, it’s a bad idea to use quotes like this, as it makes Oracle check the names in a case-sensitive manner. This means you must use quotes (and the correct case) when you later refer to that table or column. Without quotes, Oracle checks in uppercase so if you search for an unquoted lowercase “t,” it is the same as searching for a quoted uppercase “T.” Listing 6-2 demonstrates the effect of using quotes.

242


Listing 6-2. Effect of Using Quotation Marks -- Create a table without quotes apexdemo@DBTEST> create table upperCase( 2 id number, 3 data varchar2(20) 4 ); Table created. apexdemo@DBTEST> insert into upperCase 2 (id, data) 3 values 4 (1, 'data 1'); 1 row created. -- Create a table with quotes apexdemo@DBTEST> create table "MixedCase"( 2 "Id" number, 3 "Data" varchar2(20) 4 ); Table created. -- Can't insert into the table; we need to use quotes apexdemo@DBTEST> insert into MixedCase 2 (id, data) 3 values 4 (1, 'data 1'); insert into MixedCase * ERROR at line 1: ORA-00942: table or view does not exist -- Using quotes, the insert works apexdemo@DBTEST> insert into "MixedCase" 2 ("Id", "Data") 3 values 4 (1, 'Data 1'); 1 row created. apexdemo@DBTEST> select * from upperCase; ID DATA ---------- -------------------1 data 1 apexdemo@DBTEST> select * from mixedcase;

243


select * from mixedcase * ERROR at line 1: ORA-00942: table or view does not exist Creating tables with quoted names can lead to confusion. You’ll find yourself trying to query a table that you know is there, but getting this error every time: ORA-00942: table or view does not exist When you get such an error, check carefully to be sure that the table name in your query matches the one used when the table was created. If the name is mixed-case or contains spaces or other unusual characters, you’ll need to put that table name in quotes in your queries. It’s best practice not to use quotes in naming database tables, unless there’s a very compelling reason to do so. Without them, you can write your SQL statements in whichever case you like, and they will work (where work is a relative term, of course). Referring back to Listing 6-1, you can see that the query is selecting eight columns from the table, and uses the P1_REPORT_SEARCH page item to compare against the STATUS, PRIORITY, DESCRIPTION, and REPORTED_BY columns. If you edit the Report region, you’ll see that three tabs are available, as shown in Figure 6-2: •

The Region Definition tab allows you to modify the query itself, as well as adjust the positioning of the region and the other attributes that affect a page region, such as the conditional logic used to display it.

•

The Report Attributes tab allows you to modify the attributes of the individual columns of the query used in the region definition, as shown in Figure 6-3.

•

The Print Attributes tab allows you to control attributes relating to printing of the report, which we will cover in Chapter 9.

Figure 6-2. Editing a Report region

244


Figure 6-3. The Report Attributes tab The Column Attributes section of the Report Attributes tab (Figure 6-3) lists each column selected in the query. Each column has a number of attributes, such as Column Alignment, Heading Alignment, Sort Sequence, and so on. You can also drill down even further; clicking the link next to each column name provides access to more of the column’s attributes, as you will see later in this chapter. From the Column Attributes section you can control a wide variety of report aspects, ranging from the report headers to how a column should be formatted and whether that column will be enabled as a link to some other page or external web site.

Report Headers From Figures 6-1 and 6-3, you can see that the report uses the names of the columns as the column headings. Of course, as with most things in APEX, if you don’t like using the column names this way, you can change it. The choices at the top of the Column Attributes section allow you to initial cap the column names, use custom headers, use a PL/SQL function, or not to display any headers (None).

Initial Capping The Column Names (InitCap) choice uses the column names and also applies the InitCap function to them. InitCap is a simple function that changes the first letter of each word into uppercase and lowercases the subsequent letters of the word. For example, REPORTED becomes Reported. You might think that REPORTED_BY would become Reported_By, but APEX is a bit more sensible than that; it changes it to Reported By, substituting a space for the underscore character so that it looks nicer on the page.

245


Note that you can use the InitCap function in your own code, like this: apexdemo@DBTEST> select 2 3

initcap('REPORTED_BY') as colname from dual;

COLNAME ----------Reported_By However, as you can see, the underscore remains. The translation of the underscore into a space is performed by some extra code in the APEX interface (presumably by using the Translate or Replace function), rather than being part of the InitCap code.

Custom Headings You may want the heading names to be something else entirely, rather than based on the column names from the query itself. In that case, you would choose the Custom option at the top of the Column Attributes section. Then you can type anything you like into the Heading attribute for each column,

Custom Headings via a PL/SQL Function One of the more interesting choices is to use the PL/SQL option to define the report’s column headings. When you choose this option, you get an extra field in the Column Attributes section, where you can specify a function that will return the headings, as shown in Figure 6-4.

Figure 6-4. Using PL/SQL to return heading names The PL/SQL function that you enter here needs to return a string containing the headings delimited by colons. As a simple example, you can enter the following code: return 'ID:Bug Id:Reported:Status:Priority:Description:Reported By:Assigned To' This function just returns a colon-delimited string, with each entry in the string corresponding to each column sequentially. You can make this much more useful by returning a more generic list of headings. For example, let’s say you want to store all the headings for your reports in a table so you can use them in various places throughout the application (for example, you might want to reuse them in an LOV). Listing 6-3 demonstrates creating such a table.

246


Listing 6-3. Creating and Populating the report_headings Table apexdemo@DBTEST> create table report_headings( 2 3 4 5 6

id number primary_key, table_name varchar2(200), heading_id number, heading_name varchar2(200) );

Table created. apexdemo@DBTEST> insert into report_headings 2 (id, table_name, heading_id, heading_name) 3 values 4 (1, 'BUGLIST', 1, 'Id'); 1 row created. apexdemo@DBTEST> insert into report_headings 2 (id, table_name, heading_id, heading_name) 3 values 4 (2, 'BUGLIST', 2, 'Bug Id'); 1 row created. -- Extra rows added here apexdemo@DBTEST> select * from report_headings; ID ---------1 2 3 4 5 6 7 8

TABLE_NAME HEADING_ID HEADING_NAME ---------- ---------- -------------------BUGLIST 1 Id BUGLIST 2 Bug Id BUGLIST 3 Reported BUGLIST 4 Status BUGLIST 5 Priority BUGLIST 6 Description BUGLIST 7 Reported By BUGLIST 8 Assigned To

8 rows selected. Listing 6-3 creates a table called report_headings to store the headings that should be used for each table. It then inserts a record for each heading for the buglist table. (Note that we’ve omitted some of the insert statements for brevity, but the final select statement shows the records that have been inserted.) The heading_id column allows you to order the way headings are listed for a particular table. You could use the id column, but using a separate column makes it easier to rearrange the heading order later. Now you can create a packaged procedure that will, when a table name is passed into it as a parameter, return the colon-delimited list of headings that should be used, as shown in Listing 6-4.

247


Listing 6-4. Creating a PL/SQL Function to Return Headings apexdemo@DBTEST> create or replace package pkg_report_headers as 2 3 4

function get_headers(p_table in varchar2) return varchar2; end pkg_report_headers; /

Package created. apexdemo@DBTEST> create or replace 2 package body pkg_report_headers as 3 function get_headers(p_table in varchar2) return varchar2 is 4 v_temp apex_application_global.vc_arr2; 5 begin 6 select heading_name bulk collect into v_temp 7 from report_headings 8 where table_name=p_table 9 order by heading_id; 10 return apex_util.table_to_string(v_temp, ':'); 11 end; 12 end pkg_report_headers; Package body created. In the function definition, we declare a variable called v_temp as the type vc_arr2, which is defined in the wwv_flow_global package. The public synonym, apex_application_global, can be used to access this package: v_temp apex_application_global.vc_arr2; The vc_arr2 type is a PL/SQL associative array type that maps a binary integer to a varchar2. It is capable of holding an array of strings (you can look in the wwv_flow_global package to see the definition). We used a bulk collect statement instead of a cursor for loop to reduce network traffic. In a cursor for loop, a SQL statement is executed for each iteration of the loop. The bulk collect statement transfers groups of data in one round trip, which can significantly improve performance. The rows in the report_headings table where the heading_name column matches the p_table input parameter are placed in the v_temp array: select heading_name bulk collect into v_temp from report_headings where table_name=p_table order by heading_id; Once you’ve added all the heading names to the array, you use the apex_util.table_to_string function to return the array type as a string: return apex_util.table_to_string(v_temp, ':');

248


Here, the second parameter to the table_to_string function is the character you wish to use as a delimiter in the returned string. The default character is actually the colon, so you don’t need to specify it explicitly (we specified it for clarity here). You can now test to check that the code works by calling the function via some SQL, as shown in Listing 6-5. Listing 6-5. Calling the Function via SQL apexdemo@DBTEST> select 2 3

pkg_report_headers.get_headers('BUGLIST') as headings from dual;

HEADINGS ---------------------------------------------------------------------Bug Id:Reported:Status:Priority:Description:Reported By:Assigned To: So, with just a few lines of code, you are able to return a dynamic list of report headings. Using a bind variable in the call to pkg_report_headers.get_headers allows you to programmatically set or change the input parameter’s value. Because the report we’re dealing with is called BUGLIST, that’s the value that will be sent unless you change it. You can plug this into your report by entering the following code in the “Function returning colon delimited headings” text box (Figure 6-4): return pkg_report_headers.get_headers(:REPORT_NAME) You can now dynamically update the report headings and have the changes immediately reflected in the report, as shown in Listing 6-6 and Figure 6-5. Listing 6-6. Updating the report_headings Table apexdemo@DBTEST> update report_headings 2 3

set heading_name = 'Bug Status' where id = 4;

1 row updated. apexdemo@DBTEST> commit; Commit complete.

249


Figure 6-5. Updated headings reflected in the report You might be thinking that instead of using an array in the get_headers function, you could have just concatenated the headings together in a string. That’s true. However, there are quite a few places in APEX where you will work with arrays and delimited strings (for example, when working with LOVs). If you’re not already familiar with the table_to_string function and the corresponding string_to_table function, it’s worth exploring them, because you’ll find you use them more often as you become more experienced with APEX. You might also have wondered about passing in a hard-coded value ('BUGLIST') for the p_table parameter of the function. You could instead pass in the value of a page item (for example, &P1_TABLE_NAME.) that represents the table you’re using, which would allow the columns to be retrieved even more generically, if that’s something that you’d like to try (sometimes there is such a thing as trying to make your code too generic). As you can see, choosing the PL/SQL option for Headings Type is a powerful way to generate the heading names at runtime.

Named Columns vs. Generic Columns You might have already noticed that when you define the region source query for your report, you have the option to use column names based on the query or to use generic column names, as shown in Figure 6-6.

Figure 6-6. Specifying the column names type

250


The default is the Use Query-Specific Column Names and Validate Query option. As the name implies, this means that when you enter your query and click the Apply button in the Application Builder, your query will be validated (checked to ensure it is syntactically correct and so on). In contrast, if you select the Use Generic Column Names (parse query at runtime only) option, the query will not be validated within the Application Builder when you hit the Apply button. Instead, it will be parsed at runtime, and you will not be forewarned if you’ve made a mistake in the query (such as incorrectly naming a column or table). However, the difference between using named columns (as we’ll refer to query-specific column names) and generic columns runs much deeper than just whether they are parsed and validated at design time. Both types serve a specific purpose, so one type may be more applicable to a particular situation than the other.

Generic Columns When you choose the Use Generic Column Names option, you automatically lose the names of the columns in the Column Attributes section of the report, as shown in Figure 6-7. You can see that where the column names were defined by the query before, the columns are now named COL01, COL02 . . . all the way to COL60 (only the first six columns are shown in Figure 6-7).

Figure 6-7. Using generic columns You can actually control the number of generic columns by modifying the Maximum Number of Generic Report Columns value in the region source definition. The default value is 60. You can increase or decrease this number, depending on the number of columns you expect to return in your query. So, why are generic columns useful and when would you choose to use them over named columns? Generic columns are handy when you have a report where each column will look more or less the same; that is, the structure of the report is fairly uniform, and you want to define that layout in a simple way that will be repeated across each of the columns defined for the report.

251


You can see the layout definitions in the templates. The Layout and Pagination section for the report definition shows that the report is using the Standard Report template, as shown in Figure 6-8.

Figure 6-8. Layout and Pagination section for the report You can examine the Standard Report template by clicking the link in the Templates section of the Page Definition section, which will list each type of template being used by the components on the page. The template defines different sections for particular parts of the report. The Column Heading template contains the following code: #COLUMN_HEADER# This code uses the standard HTML th element to create a table header tag and specifies a class attribute of t15header, which is defined within one of the CSS files included for the standard APEX templates. The substitution values of #ALIGNMENT# and #COLUMN_HEADER# pick up the value for the alignment assigned to each column header and the column header value itself. The primary difference between generic columns and named columns is in the Column Templates section. For generic columns, the template contains this code: #COLUMN_VALUE# This looks similar to the Column Heading template, except that it uses the td element tag, a different CSS class, and the #COLUMN_VALUE# substitution variable. For every column of the report, this template substitutes the value of each column where the #COLUMN_VALUE# is specified. This is what we were referring to earlier when we said that generic columns are useful when you are not particularly concerned with the look of individual columns, but just want them all to be formatted in more or less the same way (using the same HTML markup and CSS class information). You might also notice that you can control the template by assigning conditional logic, as shown in Figure 6-9. This example uses two different column templates. The first one encloses the #COLUMN_VALUE# in bold tags ( and ) if the PL/SQL expression: '#PRIORITY#' = 'High' evaluates to true. The other template displays the column value without the bold tags if the converse PL/SQL expression is true (that is, if the priority is not High).

252


Figure 6-9. Conditional logic in a generic column template Now you might be surprised to see that even though you’re using generic columns (COL01, COL02, and so on), you can use substitution strings such as #PRIORITY# to access the value of a particular column. Even though the template is being applied to each column, you are still able to evaluate particular columns for each row to which the template is being applied. The end result of customizing the template in this way, if you hadn’t guessed already, is that all the records that have a High priority are now displayed in bold, as shown in Figure 6-10.

253


Figure 6-10. Conditional template logic applied to the report Three options are available for the conditions applied to the column templates: •

Use for Even Numbered Rows

•

Use for Odd Numbered Rows

•

Use Based on PL/SQL Expression

You can use the even and odd row options to make it easier to read the report by perhaps using a different CSS class to make alternate rows have a different background color. The PL/SQL expression option allows a great amount of flexibility to apply a different column template depending on specific criteria. Currently, the Application Builder allows you to specify up to four different column templates and associated conditions.

Named Columns Using named columns with your reports gives you much more flexibility than generic columns afford. You can customize the layout of your report template to a much greater degree since, as the name implies, you can reference each column by name in the report template. You can change the report query back to using the default Use Query-Specific Column Names and Validate Query option. However, the report will still be using a column-based template. To take advantage of named columns, you can create a new report template, as shown in Figure 6-11.

254


Figure 6-11. Creating a new report template When you create a new report template from scratch, you are given the option of making it either a column template or a row template. This determines whether the report template can use generic columns or named columns; a report that uses named columns can use a row-based template. When you create a row-based template, the definition of the template is slightly different from the definition for a column template, in that the template refers to the row rather than the column. By default, the row template contains a minimal amount of code, as shown in Figure 6-12.

Figure 6-12. Definition of a newly created row template If you changed the report to use this new template and ran the page, you wouldn’t see anything just yet, since the row template defines table rows and columns (using the tr and td elements), but there is no enclosing table element defined in the template yet (in this example anyway; yours may vary). In Figure 6-12, you can also see that the template is using the substitution strings #1#, #2#, and so on. This is known as using positional notation; for example, #1# refers to the first column in the query. To make this template a bit more visually pleasing, you can copy some of the CSS styling information that the Standard Report template uses. In the Row Template 1 box, use the following code: #4#

255


#5# Here, you’re using the positional notation to show each of the first five columns and the same t15data CSS class that the Standard Report template uses for the columns. Next, in the Before Rows section, add the following code:

Again, this is using the same sort of code that is used in the Standard Report template to create a table and then list each of the first five headings using positional notation. Finally, in the After Rows section, use the following code:

#5#
#EXTERNAL_LINK##CSV_LINK# #PAGINATION#

This was again taken verbatim from the Standard Report template. It simply inserts an extra area below the report that adds the ability to paginate the report and export it to a comma-separated values (CSV) format file. If you save the template and run the report now, it will look exactly as it did before. The report template was changed, but the report is still using the Standard Reports template. The template setting needs to be changed to Buglist Report as shown in Figure 6-13.

Figure 6-13. Selecting the Buglist Report template

256


If you now run the page, you should see the report looks pretty much as it did with the Standard Report region, although it is displaying only the first five columns of the query, as shown in Figure 6-14.

Figure 6-14. Using the row-based template As this point, you are probably wondering why you should go to the extra effort of using row-based templates when they end up looking the same as column-based templates. But in this template, you’re still using positional-based notation. You have not yet taken advantage of the extra flexibility attained by referring to the columns by name. In the original report, all the columns are in the same row. If a lot of data has been entered in the Description column, that could make the report difficult to read (perhaps making the report overly wide or limiting the amount of text that can be shown in the Description column). Wouldn’t it be nice if you could make the Description column appear in a separate row below the main detail row of the record? Well, as you’ve no doubt guessed, you can accomplish this sort of layout by using row-based templates combined with named columns. First, you need to convert the template to use the named columns rather than the positional notation. Change the Row Template 1 section to use the code shown in Listing 6-7.

257


Listing 6-7. Row Template Using Named Column Notation #ASSIGNED_TO#

This code adds the extra columns to the code. Note that in the query, you use the name of the actual column, rather than the heading name. Also modify the Before Rows section to include the extra heading names, as shown in Listing 6-8. Listing 6-8. Extra Heading Names in the Before Rows Template

Note that you could hard-code the names of the headings in the template. However, using positional notation gives you the ability to modify the headings using the options covered earlier in this chapter (such as via a PL/SQL function), without needing to modify the template again. Now you should have a template that makes the report look exactly as it did before. Since you’re now using named columns, you can modify the row template a bit more to move the Description column into a separate row, as shown in Listing 6-9. Listing 6-9. Moving the Description Column into a Separate Row


This code creates another row below the original one and makes the Description column span the entire width of the row (by using the colspan attribute to make it span seven columns, which is the number of columns in the row above it). Since you have changed the order of the columns in the row, you also need to modify the Before Rows template, as shown in Listing 6-10. Listing 6-10. Modified Before Rows Template

#8#
#ASSIGNED_TO# #DESCRIPTION#

The only change in Listing 6-10 is that you have removed the line that represented the heading for the Description column (which was column 6 in positional notation). When you mix positional notation with named notation, things can become confusing. It’s not immediately apparent which positional element represents which column. If you probably won’t want to later change the column headings in the report definition (or dynamically), you could hard-code them to make it easier to read and modify the template. After these changes, the report looks like the one shown in Figure 6-15.

Figure 6-15. Using named columns to affect the layout

259


 Note It is debatable whether the report in Figure 6-15 is actually any easier to read than it was before (in fact, you could argue that it’s slightly more difficult to read, since the eye does not scan quite so easily across a nonuniform order like this). However, the point of this exercise is just to demonstrate how easily you can modify the layout of the report using named columns and templates. You could make this report easier to read by using a different CSS class for the Description column, so that the background of that column is a slightly different color.

We can extend this example a bit further, making it a little less cluttered and perhaps more useful to the end users. Imagine that the users want to see only the description from bugs that are still classified as Open. You can do this quite easily by using conditional logic with the row template, much as you saw with the earlier generic columns example. First, modify the row template to include an extra column before the Description, just to add some space and make it easier to read, as shown in Listing 6-11. Listing 6-11. Inserting a Column Prior to Description

Next, add a condition to this row template, which is a PL/SQL expression: '#STATUS#' = 'Open' This template will be used for records with an Open status. Listing 6-12 shows a second template to be used when the status is not Open (using the reverse PL/SQL expression logic). This second template does not display the Description column at all. Listing 6-12. Row Template for Closed Bugs


If you now run the report, it should look similar to Figure 6-16. Notice that where the bug is classified as Closed (Bug ID 2 in Figure 6-16), no description is shown underneath.

Figure 6-16. Using conditional logic in a row template Row-based templates also allow you to use a number of conditional templates, based on even rows, odd rows, or PL/SQL expressions. Named column templates are probably one of the most underused features of APEX. The amount of control and flexibility they give you is amazing. You can build some really complex-looking reports— ones that don’t even look like standard tabular reports—by applying logic to vary how each individual row is represented in the report.

Report Pagination When you define your report template, you can also specify a pagination scheme for the report (look back at Figure 6-8). APEX 3.0 currently supports the following pagination schemes: •

Row Ranges 1-15 16-30 (with set pagination)

•

Row Ranges 1-15 16-30 in select list (with pagination)

•

Row Ranges X to Y (no pagination)

•

Row Ranges X to Y of Z (no pagination)

•

Row Ranges X to Y of Z (with pagination)

•

Search Engine 1,2,3,4 (set based pagination)

•

Use Externally Created Pagination Buttons

•

Row Ranges X to Y (with next and previous links)

261


Even though some of the schemes say no pagination, they still allow you to move through your report resultset in different ways. Enabling pagination in your report and the type of pagination style you use can have an impact on the performance and usability of your report. To demonstrate the effect of the different pagination schemes, let’s consider a report that returns a large number of rows. The report is based on a new table called big_emp. This table contains repeated records from the familiar emp table, as well as the same indexes, for a total of more than 114,000 records, as shown in Listing 6-13. You can use any large table to test pagination yourself, since the point is to see the differences when using the various pagination schemes with the same data. Listing 6-13. Definition of the big_emp Table apexdemo@DBTEST> desc big_emp; Name Null? ------------- -------EMPNO NOT NULL ENAME JOB MGR HIREDATE SAL COMM DEPTNO apexdemo@DBTEST> select

Type --------------NUMBER(4) VARCHAR2(10) VARCHAR2(9) NUMBER(4) DATE NUMBER(7,2) NUMBER(7,2) NUMBER(2) count(*) from big_emp;

COUNT(*) ---------114688 For a quick test, let’s just create a new page in the application (to be removed later), with a new SQL Report region, using the following SQL in the region source: select empno, ename, job, mgr, hiredate, sal, comm, deptno from big_emp Now we need some way of measuring the relative performance of each of the pagination types. This could be done in various ways, such as by running the page in debug mode and examining the timings, or by generating a trace file for the page and examining it with TKProf. However, a much easier way (though not as accurate in granularity) is to use the substitution string #TIMING# within the footer of the Report region. Then APEX will substitute the string for the time (in seconds) that it took to render that particular region; in other words, how long it took to run the query and generate the report for those particular rows retrieved. Figure 6-17 shows the timing information being displayed below the report when using the Row Ranges 1-15 16-30 (with set pagination) scheme. Notice the information above the report that’s new with APEX 4.0. The report is telling you that it’s returning too many rows to be

262


practical and asks that you apply some type of filter. This can easily be suppressed via the the Pagination section in the Report Attributes page.

 Tip You can use the #TIMING# substitution string in any region type. It can be a great way to track down performance issues in your application, or even just to provide some visual feedback to your end users to let them know how quickly your pages are being generated.

Figure 6-17. Using the #TIMING# substitution string in a region To benchmark the pagination types, we timed how long it took to retrieve the first set of results (records 1–15), and then how long it took to page to other results (records 61–75 and records 136–150). This process simulates a user paging through the resultset (although, typically, users might not move that many pages into the results). This test was with the report’s Max Row Count set to 120,000, to allow paging to the end of the resultset (in practice, you wouldn’t want to return this many rows, but this test is to illustrate the effect that the different pagination schemes have on performance). Table 6-1 shows the results.

263


Table 6-1. Pagination Style Benchmarks with a Max Row Count Setting of 120,000

Pagination Style

Rows 1–15

Rows 61–75

Rows 136–150


13.21

13.36

15.99


13.20

14.90

15.20

Search Engine 1,2,3,4 (set-based pagination)

13.30

14.20

14.87


0.21

0.26

0.28

 Note We ran our test on relatively modest hardware. You might get much faster times for your tests. The point is to illustrate the relative differences between timings, not to see how fast you can make each pagination type.

You can see from Table 6-1 that there’s a huge difference in performance between the pagination styles that had to keep track of the number of overall results (such as Row Ranges X to Y of Z) compared with the simple Row Ranges X to Y pagination type. Also, remember that for some of the pagination types, there is no quick way for the user to jump to a particular set of results, which means that the performance effect is cumulative (that is, if it takes 5 seconds per page, then it might take 25 seconds to reach the fifth page if the user can’t skip ahead). These benchmarks illustrate that if you have a very large resultset, the type of pagination you select can significantly affect how usable your report is for the end users. You can greatly improve the performance of your reports by keeping the Max Row Count setting to a sensible value (or even allowing the user to define it). We are all very familiar with the typical search engines available on the Internet today. When you search for something with these search engines, you usually get many hits, often running to many pages of results. Typically, you’ll use only the first page or so of results, rather than going to the twentieth or fiftieth page (since the first results must be most relevant, right?). You can apply the same logic to your reports, showing, say, just the first 500 results. Table 6-2 shows the results of rerunning the same benchmark, but this time with the report’s Max Row Count set to 500 (which is the default value if you don’t specify one). Table 6-2. Pagination Style Benchmarks with a Max Row Count Setting of 500

264

Pagination Style

Rows 1-15

Rows 61-75

Rows 136-150


0.30

0.33

0.32



0.19

0.29

0.34

Search Engine 1,2,3,4 (set-based pagination)

0.28

0.31

0.31


0.23

0.24

0.28

The results in Table 6-2 clearly show a dramatic improvement for those pagination types that provide feedback about the maximum number of rows returned. So, if your users can live without knowing that XXX number of results were returned, you might use this approach. Note that this might not be preferable in all cases, so you should use your judgment about where reducing the Max Row Count setting for the report might be appropriate.

Break Formatting You can use break formatting to specify whether a particular column will repeat values across rows. For example, if the current record contains the same value for a particular column that the preceding row contained, you can suppress outputting the value to make the report slightly easier to read. An example of a column for which you might not want to repeat values is one that shows the department number in an employee report. Using the employee report from the previous examples, rearrange the order to display the department number first. You can do this quite easily via the Column Attributes section, as shown in Figure 6-18.

Figure 6-18. Rearranging columns in the Column Attributes section Here, you can use the small up and down arrows to the right of the Sort Sequence select list to move the DEPTNO column so that it is the first column in the list of columns. When you use a column-based template, as discussed earlier in the chapter, you don’t need to also modify the query to rearrange the column order in the report. When the template uses named columns, though, you do need to modify the template to rearrange the order.

265


 Note In previous versions of APEX, each time you moved a column, you had to resubmit the page to the server to effect the change. Now, that work is performed via Ajax, and no full page refresh is required. This makes your application much more responsive, and it’s quicker for users to make changes to their data.

Next, go to the Break Formatting section of the report, and you will see the options for breaks are First Column; First and Second Columns; and First, Second and Third columns. For this example, choose First Column. The resulting report is shown in Figure 6-19. It no longer shows repeated data for the DEPTNO column, so that it becomes much easier to visually group the data in the report.

Figure 6-19. Using a report break to avoid repeated columns As you can see in the Break Formatting section, some other interesting options are available for report breaks. One is to repeat the report headings whenever a break is performed, which makes it even easier to visually comprehend the data in the report. (Note that you’ll need to make sure your returned data is ordered sensibly using order by so that the breaks can be performed.) You can also add some extra text before break columns or after. Figure 6-20 shows some extra tweaks to repeat the report heading whenever the DEPTNO value changes and to display the sum of the salary for that DEPTNO. Figure 6-21 shows how different the report looks with just a bit of work. Of course, you should take advantage of break formatting only when it makes sense to do so with regard to both your business rules and the data you are displaying. Otherwise, the report can actually become more confusing to read.

266


Figure 6-20. Customizing break formatting to display sums and headings

267


Figure 6-21. Report showing department breaks and sums It is important to note that you could have achieved almost the same results had the report been built as an Interactive Report rather than in the Classic style. Using the Action button on an Interactive report, you can create control breaks on the fly. If you wanted specific text displayed on each break, though, you’d still have to do some work.

268


Column Formatting You might think that formatting a report column refers only to things like controlling the currency symbol or perhaps setting the number of decimal places displayed in a numeric value. However, APEX allows a great deal of control over the column formats, so you can think of formatting as referring to the onscreen display of any type of data represented by your columns.

Number and Date Formatting The Column Formatting section of the Column Attributes section for a report includes a Number/Date Format setting. As an example, the Buglist report currently displays the date that the bug was reported in the format DD-MON-YY. You can modify that by changing the formatting of the REPORTED column, as shown in Figure 6-22.

Figure 6-22. Modifying the date formatting for the REPORTED column Figure 6-22 shows the Number/Date Format value for the REPORTED column changed to use DDMON-YYYY HH:MIPM. This value was selected from the pop-up list for this field. The text field is a freeformat field, so you can type anything into it, as long as the value makes sense for the particular field and is valid. For example, you will get strange results if you try to apply a date-format mask to a numeric column, or if you specify invalid characters in your date-format mask. Note that no validation of the input text takes place at design time; it is used only at runtime. If you ran the report after making this change to the date format, you’d find that the REPORTED column now displays values such as 27-JAN-2006 12:00AM. In our example, all the times display as 12:00AM, since only a date (not a time component) was used when each record was created. Thus, the time defaults to 12:00AM. Another interesting format mask for dates uses the keyword SINCE, which displays a text description of how long ago that date occurred. For example, you might see 6 months ago, 2 days ago, 8 minutes ago, and so on. This makes it much easier for the end users to immediately see how long ago an event occurred, rather than having to mentally calculate it themselves. Also, when you use the SINCE mask, the value is calculated each time it is used, so you’ll see the age of the record increasing each time you view the report—for example, from 8 minutes ago to 9 minutes ago and so on.

269


CSS Classes You can also assign particular CSS classes and styles to the column, For example, if you wanted to display the REPORTED field in bold, you could take advantage of the predefined CSS class called fielddatabold, which is defined in the standard APEX CSS files. All you would need to do is to enter the text fielddatabold into the CSS Class field in the Column Formatting section, and APEX would enclose your column data in an HTML span element and assign the class to it, as shown here: 27-JAN-06

Highlighted Words You can also enter a comma-delimited list of words into the Highlight Words text field in the Column Formatting section, and APEX will automatically highlight any words that match the column data when you run the report. It does this by wrapping any matching words in an HTML span element and applying a CSS style to that span. For example, entering JAN in the Highlight Words field generates the following HTML (manually broken here): Although this built-in highlighting is great, considering you get it for free, you have no control over how the word is highlighted—you can’t modify the CSS styling that is used. So unless you always want your words highlighted in bold red text, you might find this feature of limited use.

HTML Expressions Perhaps the most interesting, yet often overlooked, part of the Column Formatting section is the HTML Expression text field. This is extremely powerful, since it allows you to essentially apply another template to the column. As an example, let’s imagine that you’d like the Buglist report to give the end users a quick way to email the person who reported the bug. To do this, you could turn the REPORTED_BY column into a link that, when clicked, launches the default e-mail client and automatically fills in the e-mail address of the person who reported the bug. This is not quite as difficult as it might seem at first, but it does require changing the report a bit. First, you need to modify the query used for the report so you can extract the e-mail address of the person who reported the bug. Recall that the query was originally as follows: select "ID","BUGID", "REPORTED","STATUS", "PRIORITY","DESCRIPTION", "REPORTED_BY", "ASSIGNED_TO" from "BUGLIST" where

270


( ... where clause omitted ) Currently, the users who reported bugs are not maintained in the user_repository table, so you wouldn’t be able to get the e-mail address from there. (The reported_by field is actually a free-format field, so any name could be typed in it.) For this example, we have inserted records into the user_repository table to represent each person who has reported a bug, and also modified the bugediting screens to allow only the reporting person to be selected from a list of people in the user_repository table. We will not show all the steps we performed, since they are not directly relevant to this example, but you can see the changes in the application export included with the downloadable code provided for this chapter. You can now change the report query to extract the e-mail address from the user_repository table by performing a subquery, as shown in Listing 6-14. Listing 6-14. Subquery to Extract E-Mail Addresses SELECT bl.id, bl.bugid, bl.reported, bl.status, bl.priority, bl.description, bl.reported_by, bl.assigned_to, (select ur.email from user_repository ur where ur.username = bl.reported_by) as reported_email, (select initcap(ur2.forename) || ' ' || initcap(ur2.surname) from user_repository ur2 where ur2.username = bl.reported_by) as reported_full_name FROM buglist bl WHERE( ... where clause omitted ) This query is essentially the same as before, except now the subquery looks up the e-mail address from the user_repository table and also generates the full name of the user by using the InitCap function to uppercase the forename and surname of the person who reported the bug, This is necessary because the reported_by field now contains the username of the user, rather than the free-format text it contained previously. Note also in Listing 6-14 that table aliases have been added to make it easier to remove any ambiguity about which table the columns reference. If you now looked at the Report Attributes section, you would see the REPORTED_EMAIL and REPORTED_FULL_NAME columns added to the list. You could just modify your report template to display this new column, but it would be nice to use it in a link from the user’s full name. To do that, enter the following code in the HTML Expression field for the REPORTED_BY column: #REPORTED_FULL_NAME#

271


Even though you place this code into the HTML Expression field for the REPORTED_BY column, you are actually referencing the two other columns you haven’t directly used in the report. The code will generate an HTML a (anchor) element, with the special href attribute of mailto:, which most modern browsers recognize as meaning that the default mail client should be launched when the user clicks the link. You pass the value of the #REPORTED_EMAIL# column into the href, so that when the default mail client launches, it generates a new e-mail message and uses the value of the REPORTED_EMAIL column as the e-mail address to which to send the message. By using the REPORTED_FULL_NAME column value inside the HTML anchor, the text that is displayed for the link is the user’s full name, rather than the login username, which you would have gotten if you had used #REPORTED_BY# instead. But why use the REPORTED_BY column here, when it isn’t actually displayed in the report? You could have just as easily shown the REPORTED_EMAIL column in the report, and used the same HTML expression to format it slightly differently. Well, that’s a good question. Doing that would make it slightly less confusing when you return to this code in six months or so. However, doing it this way demonstrates that in the HTML expression, you can reference columns other than just the current one. This is what gives HTML expressions their power. Using them, you can completely transform the way a particular column is represented on the screen. You can use HTML expressions in many different ways. Typical uses include making custom links (as in this example), generating the correct HTML for an image to be displayed, and linking in some custom JavaScript for that item. One place you should definitely consider using HTML expressions is if you find yourself including HTML markup inside your queries. For example, rather than write code like this: select name, '

Pro Oracle Application Express 4

Read more


Read more

Beginning Oracle Application Express 4

Read more


Read more

Oracle Application Express 4 Recipes

Read more


Read more


Read more


Read more

Beginning Oracle Application Express

Read more

Expert Oracle Application Express

Read more

Beginning Oracle Application express

Read more

Oracle Application Express 4.0 with Ext JS

Read more

Oracle Application Express 3.2: The Essentials and More

Read more

Expert Oracle Application Express Plugins: Building Reusable Components

Read more

Expert Oracle Application Express Plugins: Building Reusable Components

Read more

Pro Oracle SQL

Read more

Beginning Oracle Application Express (Wrox Programmer to Programmer)

Read more

Oracle Real Application Clusters

Read more

Oracle Application Integration Architecture

Read more

Oracle Application Integration Architecture

Read more

Pro Oracle SQL (Expert's Voice in Oracle)

Read more

Pro Oracle SQL (Expert's Voice in Oracle)

Read more

Pro Oracle Collaboration Suite 10g

Read more

Oracle Application Server Portal Handbook

Read more

Oracle Application Server 10g Essentials

Read more

Oracle Application Server Portal Handbook

Read more

DVD Studio pro 4

Read more

Recommend Documents




CYAN MAGENTA YELLOW BLACK PANTONE 123 C BOOKS FOR PROFESSIONALS BY PROFESSIONALS ® THE EXPERT’S VOICE ® IN ORAC...


Beginning Oracle Application Express 4 ■■■ Doug Gault Karen Cannell Patrick Cimolini Martin D’Souza Timothy St. Hilaire...


BOOKS FOR PROFESSIONALS BY PROFESSIONALS ® Zehoo RELATED Oracle Application Express 4 Recipes If you’re a hands-on pe...




THE EXPERT’S VOICE ® IN ORACLE Beginning Oracle Application Express 4 Your ticket to easy and robust web-a...

Beginning Oracle Application Express

Expert Oracle Application Express

Report "Pro Oracle Application Express 4"

Your name

Email

Reason

Description

Copyright © 2024 EPDF.PUB. All rights reserved.
About Us | Privacy Policy | Terms of Service | Copyright | DMCA | Contact Us | Cookie Policy

Sign In

Email

Password

Remember me Forgot password?

Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & close

#8#
#DESCRIPTION#
#REPORTED_BY# #ASSIGNED_TO#

27JAN-06