Skip Headers

Oracle® Application Server Portal Configuration Guide
10g (9.0.4)
Part Number B10356-01
Go To Documentation Library
Home		 Go To Product List
Solution Area		 Go To Table Of Contents
Contents		 Go To Index
Index

Go to previous page Go to next page

C Using OracleAS Portal Installation and Configuration Scripts

After installing OracleAS Portal as part of the Oracle Application Server installation, several scripts are available for post-installation configuration.

The specific topics covered in this appendix include:

C.1 OracleAS Web Cache Configuration Scripts

This section shows how you can choose to run OracleAS Web Cache configuration scripts to configure OracleAS Portal to work with OracleAS Web Cache. You can use this method in lieu of running OPCA in the MIDTIER mode to adjust OracleAS Web Cache specific settings, such as the OracleAS Web Cache host, or OracleAS Web Cache invalidation port. Furthermore, this section describes how you can disable OracleAS Web Cache and manage the invalidation message processing job using the script cachjsub.sql.

Specific topics covered in this section include:

C.1.1 Using cachset.sql

The script cachset.sql is used to turn on or off the use of OracleAS Web Cache. The script can be found in the ORACLE_HOME/portal/admin/plsql/wwc directory.

To use cachset.sql, connect to SQL*Plus as the schema owner and run cachset.sql as follows: 

SQL>@cachset.sql

At the prompt, enter on, to enable the use of OracleAS Web Cache, and off, to disable it.

C.1.2 Managing the Invalidation Message Processing Job Using cachjsub.sql

OracleAS Portal uses caching to improve its performance. One type of caching it uses is the invalidation-based caching. In invalidation-based caching, OracleAS Portal caches various objects (pages, portlets, and so on) for a set amount of time. When these objects are requested, they are retrieved from the cache, if available; otherwise they are regenerated from the Oracle Application Server Metadata Repository. The cache for these objects will expire when the maxcache time has been reached, or when the objects are explicitly invalidated (expired) by invalidation messages.

OracleAS Portal uses invalidation messages when it needs to expire objects in the cache. Invalidation messages are categorized as hard and soft invalidations. Hard invalidations take effect immediately, that is, the objects that they intend to invalidate expire from cache immediately. Soft invalidations take effect when they are processed by the invalidation processing job. The frequency by which the invalidation job executes is configurable. This is done using the cachjsub.sql script.

To change the execution frequency of the invalidation processing job:

  1. Locate the following directory:

    ORACLE_HOME/portal/admin/plsql/wwc

  2. On the database where the Portal schema is installed, log on to SQL*Plus with the appropriate user name and password for that schema.

    For example: 

    sqlplus portal/portal
  3. Enter the following command to update the execution frequency of the invalidation job: 

    SQL> @cachjsub.sql <start_time> <start_time_fmt> <interval_mins>

    cachjsub.sql takes three parameters:

    Example 1: 

    SQL> @cachjsub.sql START null 120

    Example 2: 

    SQL> @cachjsub.sql '02-22-2003 7:30' 'MM-DD-YYYY HH:MI' 1440

C.2 Disabling the IP Check of Cookie Validation

As part of the process of validating the session cookie of a user's request (even if that user is PUBLIC), Portal performs a comparison between the IP address stored in the cookie with the IP address of the current client. Only if the two values are the same will OracleAS Portal consider the request legitimate.

When a proxy exists between the user's client and the portal, the IP address stored in the session cookie is that of the proxy, and not that of the client.

Some proxy systems make use of multiple servers, each with different IP addresses. In these circumstances, it is conceivable that the original request from a user's client (the request that causes the session cookie to be created) is routed through one proxy server and that a subsequent request is routed through another, separate, proxy server. In these cases, the IP addresses compared by OracleAS Portal will differ. The request will raise a security violation during the IP checking step. And access to the page will be denied.

Depending on the network configuration into which the Oracle Application Server is installed, it may be necessary to disable IP checking in cookie validation.

To change the state of IP checking in cookie validation, you must use SQL*Plus to update data in both the portal schema and the SSO schema as detailed in Table C-1.

Table C-1  Enabling and Disabling the IP Check
Portal Schema SSO Schema

Enable

IP Checking

update wwsec_enabler_config_info$

set url_cookie_ip_check = 'Y';

commit;

update wwsec_enabler_config_info$

set url_cookie_ip_check ='Y';

update wwsso_ls_configuration_info$

set cookie_ip_check = 'Y';

commit;

Disable

IP Checking

update wwsec_enabler_config_info$

set url_cookie_ip_check = 'N';

commit;

update wwsec_enabler_config_info$

set url_cookie_ip_check ='N';

update wwsso_ls_configuration_info$

set cookie_ip_check = 'N';

commit;

C.3 Using the secupoid.sql Script

By default, OracleAS Portal connects to Oracle Internet Directory using LDAP without SSL. If the Oracle Internet Directory server is configured for an SSL port, though, OracleAS Portal can be configured to use LDAP over SSL, also known as LDAPS.

See Also:

Oracle Internet Directory Administrator's Guide

To configure OracleAS Portal to use SSL to connect to Oracle Internet Directory, you must run the secupoid.sql script. This script enables you to change the following OracleAS Portal configuration parameters related to Oracle Internet Directory:

When you install OracleAS Portal, it is automatically configured to use an Oracle Internet Directory server. However, you may want to change some settings, such as whether to use SSL, after installation. To change to an SSL connection for Oracle Internet Directory, simply run the secupoid.sql script in the PORTAL schema to specify the LDAPS port instead of the LDAP port, and indicate that you want to use SSL.

Running the secupoid.sql Script

This section illustrates a sample execution of secupoid.sql from SQL*Plus.

In the example, Oracle Internet Directory was initially configured to run LDAP on port 389. Later, an LDAPS port was activated on 636. Since the server name does not change, we retain the old value, update the port, and indicate that we want to use SSL by setting the Use SSL? value to Y. When you run the script, it displays the current configuration and lets you replace any of the configurable settings. The script also enables you to update OracleAS Portal's Oracle Internet Directory cache after running it. Since activating SSL does not change any of the Oracle Internet Directory information cached by OracleAS Portal, it is not usually necessary to refresh the cache in this case. 

SQL> @secupoid 
Current Configuration 
-------------------- 
OID Host: oid.domain.com 
OID Port: 389 
Application DN: 
orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext 
Application Password: 3E8C2D1B87CB61011757239C5AA9B390 
Use SSL? N 

PL/SQL procedure successfully completed. 

Updating OID Configuration Entries 
Press [Enter] to retain the current value for each parameter 
For SSL Connection to LDAP, specify "Y"es or "N"o 
------------------------------------------------ 
Enter value for oid_host: 
Enter value for oid_port: 636 
Enter value for app_password: 
Enter value for use_ssl_to_connect_to_ldap: Y 
Enter value for refresh_with_new_settings: N 

PL/SQL procedure successfully completed. 

No errors.

After executing the script, OracleAS Portal is configured for LDAPS access of Oracle Internet Directory.

See Also:

Oracle Application Server 10g Security Guide

C.4 Using the secjsdom.sql Script

If you have your Oracle Internet Directory and OracleAS Portal servers residing in different domains, you must explicitly set the JavaScript domain for OracleAS Portal such that it can resolve user and group lists of values. To do this, you must use the secjsdom.sql script located in the directory ORACLE_HOME/portal/admin/plsql/wwc.

Suppose your installation has OracleAS Portal configured to use an Oracle HTTP Server other than DAS. In this situation, you must have a common domain, so that the values can be transferred from the list of values displayed by DAS to the page displayed by OracleAS Portal.

To create a single domain in this case, do the following:

  1. Login to SQL*Plus as PORTAL.

  2. Run the following SQL script: 

    SQL> @secjsdom.sql <domain_name>

If, in the preceding example, the DAS servlet is running on a machine infra.acme.com and OracleAS Portal is running on a machine portal.acme.com, then the secjsdom.sql script should be invoked like this: 

@ SQL> @secjsdom.sql acme.com

Performing this procedure enables you to run Oracle Internet Directory lists of values from OracleAS Portal in either Netscape, or Microsoft Internet Explorer. When using lists of values, a transit window is displayed in addition to the list of values itself. The transit window is required to pass values to OracleAS Portal without forcing pages to reset their domain.

See Also:

Oracle Application Server 10g Security Guide

C.5 Configuring the Portal Session Cookie

OracleAS Portal uses a session cookie to maintain session state for portal applications. For portal to work correctly, the client browser must be configured to accept cookies from the server. Upon installation, the portal session cookie has a default name, scope, and security that are set appropriately for most installations. This section describes these defaults, and how they can be changed if needed.

C.5.1 Configuring the Cookie Name

By default the portal's session cookie is named portal after the default Database Access Descriptor (DAD) used to access the Portal schema. You can use Oracle Enterprise Manager to change the cookie name, if it needs to explicitly be set to something else. To do this, you must access the DAD Edit page in the Oracle Enterprise Manager Application Server Control. This page is located under mod_plsql services of the Portal middle-tier component. The cookie name can be set on the Document Alias and Session Parameter page. To change the name of the cookie, provide the desired name in the Session Cookie Name field of the Session Cookie section.

C.5.2 Configuring the Scope of the Cookie

Note:

You should make these changes when there is no traffic on the portal, otherwise existing sessions will experience session errors (ORA-20000) after you change the session cookie name.

In cases where you want access to the same portal from two middle-tiers at the same time, or if you want to open the portal cookie domain as required by the PL/SQL Adapter functionality, you must define the scope of the OracleAS Portal session cookie to be sent to all the middle-tier servers involved in the architecture. By default, the session cookie's domain is scoped to the host from which it was generated. The path for the cookie is set to "/".

For example, if the cookie was generated from www.oracle.com, then the cookie domain is www.oracle.com. However, let's say that another server, portal.oracle.com is also a middle-tier server that needs access to that session cookie. Then the cookie domain would need to be widened so that the portal.oracle.com server can also see the cookie.

Follow these steps to modify the scope of the portal session cookie:

  1. Locate the following directory: 

    ORACLE_HOME/portal/admin/plsql/wwc
  2. On the database where your OracleAS Portal schema is installed, log on to SQL*Plus as the portal schema. For example: 

    sqlplus portal/portal_pwd
  3. Enter the following command: 

    SQL> @ctxckupd
OracleAS Portal
Current Settings for Portal Session Cookie:
Cookie Domain : Only send cookie back to originating host:port
Set Cookie as Secure: Y
Enter the domain for the session cookie: .oracle.com
Should cookie be flagged as secure for HTTPS sessions? (Y/N): N
Settings changed to
Cookie Domain : .oracle.com
Do not set cookie as secure. (N)
SQL>

    This enables you to set the cookie domain for the session cookie. In this example, the cookie domain is set to .oracle.com.

    Note:

    If you want to use different listeners or keep the session cookie throughout different domains, specify a Cookie Domain to be the host name only. For example, if you access OracleAS Portal from two machines:

    • machine1.us.oracle.com:3000

    • machine2.us.oracle.com:4000

    When running ctxckupd.sql, set the cookie domain to .us.oracle.com.

    Note:

    The cookie domain also determines the scope of the NLS_LANGUAGE cookie, which is a persistent cookie that determines the user's preferred language. This NLS_LANGUAGE cookie is set when selecting languages in the set language portlet.

C.5.3 Securing the Cookie

In this release of OracleAS Portal, the script ctxckupd.sql contains an additional option, Set Cookie as Secure.

The default location for this script is ORACLE_HOME/portal/admin/plsql/wwc. When you run this script, you see the following output: 

SQL> @ctxckupd
OracleAS Portal
Current Settings for Portal Session Cookie:
Cookie Domain : Only send cookie back to originating host:port
Set Cookie as Secure: Y
Enter the domain for the session cookie...
Leave blank to scope to originating host:
Should cookie be flagged as secure for HTTPS sessions? (Y/N): N
Settings changed to
Cookie Domain : Only send cookie back to originating host:port
Do not set cookie as secure. (N)
SQL>

Set Cookie as Secure indicates that the cookie should be sent back to the server if the request is over an HTTPS connection only. This setting ensures that the session cookie is not transmitted over an insecure connection when it needs to be protected. By default, this option is set to Yes and is sufficient for most deployments.

In some cases, you may need to set the Set Cookie as Secure option to No. For example, if your portal is accessed over both HTTP and HTTPS and you want the session cookie to be shared across both protocols (possible if they are running on the default ports 80 (http) and 443 (https)). In this instance, when Set Cookie as Secure is set to No, the same cookie produced over an https request, is sent over any subsequent http requests.

C.6 Managing the Session Cleanup Job

OracleAS Portal and OracleAS Single Sign-On perform session management similar to other Web-based applications. Sessions are tracked with cookies. Session information is stored in a table in the Portal and OracleAS Single Sign-On schema. When a user logs out, the session information is marked inactive. A DBMS job subsequently cleans up the inactive rows.

The session table accumulates a number of rows that are flagged as active. When a user shuts down the browser instead of logging out, the row is "active", even though it is not actually in use. The cleanup job cleans up the active rows that are older than a specified duration.

When OracleAS Portal is installed, a DBMS job is installed to perform session cleanup of the session table, WWCTX_SSO_SESSION$. The cleanup job is set to run every 24 hours. The first scheduled cleanup occurs 24 hours after the installation of the job.

When the job runs, it deletes all inactive sessions and all sessions marked active (WWCTX_SSO_SESSION$.ACTIVE = 1), that are older than 7 days (WWCTX_SSO_SESSION$.SESSION_START_TIME < sysdate - 7).

These default settings can be modified by running some job management scripts in the Portal schema to manage Portal sessions, or in the OracleAS Single Sign-On schema to manage OracleAS Single Sign-On sessions. They utilize the same session management infrastructure.

Follow these steps to obtain the current cleanup job information:

  1. Locate the following directory: 

    ORACLE_HOME/portal/admin/plsql/wwc
  2. On the database where the Portal or OracleAS Single Sign-On schema is installed, log on to SQL*Plus with the appropriate user name and password for that schema.

    For example: 

    sqlplus portal/portal
  3. Enter the following command to get the current job information: 

    SQL> @ctxjget

    The command results in the display of the currently installed job information, as returned by the DBMS_JOB package: 

    The session cleanup job is job ID 7381
dbms_job.isubmit(job=>7381,what=>'begin execute immediate''begin
wwctx_sso.cleanup_sessions(p_hours_old => 168); end;''; exception when
others then null; end;',next_date=>to_date('2001-04-17:14:07:20',
'YYYY-MM-DD:HH24:MI:SS'),interval=>'SYSDATE + 24/24',no_parse=>TRUE);

PL/SQL procedure successfully completed.

The results indicate which procedure is executed, what parameters are passed to it, and when the next invocation is to occur. This particular example indicates that the job is to cleanup active sessions that are a week old (168 hours). It also indicates that the next scheduled job execution is on 4/17/2001 at 5:14 pm, and the job should run every 24 hours thereafter.

If the job execution must be modified, either to adjust the age of sessions that should be deleted, or to increase or decrease the frequency of cleanup, you can run the ctxjsub.sql script to submit modified execution parameters.

Follow these steps to submit modified job execution parameters:

  1. Locate the following directory: 

    ORACLE_HOME/portal/admin/plsql/wwc
  2. On the database where the Portal or OracleAS Single Sign-On schema is installed, log on to SQL*Plus with the appropriate user name and password for that schema. For example: 

    sqlplus portal/portal
  3. Enter the following command to submit new cleanup job information: 

    @ctxjsub <hours_old> <start_time> <time_format> <interval_hours>

Table C-2 lists the ctxjsub parameters.

Table C-2  ctxjsub Parameters
Parameter Description

hours_old

The age of an active session that should be deleted.

start_time

The time that the next job should run.

time_format

The time format string that specifies how start_time is formatted.

interval_hours

The amount of time, in hours, between runs of the cleanup job.

For example: 

SQL> @ctxjsub 200 '04/17/2001 10:00' 'MM/DD/YYYY HH24:MI' 12

The job information is displayed, similar to: 

Created path for job id.
DBMS_JOB id = 7381
Cleanup job updated. Job ID = 7381

PL/SQL procedure successfully completed.

The cleanup job submission script can be run any number of times to modify the execution parameters. Each invocation updates the job information associated with the job ID for the cleanup job. This job ID is maintained in the preference store so that the job information is updated instead of submitting multiple jobs.

You can also specify a start_time of START, in which case, the time_format parameter is ignored, but you still need to pass it a value (such as NOW). The result is to run the job <interval_hours> hours from now: 

SQL> @ctxjsub 168 START NOW 24

This submits the job as it does in the installation.

If you want the cleanup job to execute immediately, then obtain the job ID by calling ctxjget.sql. Once you know the job ID, you can execute the job by issuing the following command in the product schema: 

SQL> exec dbms_job.run(7381);

In the preceding example, 7381 is the job ID returned by the call to ctxjget.sql. When you execute a job in this manner, the next automated invocation of the job occurs at interval_hours after this manual invocation. To run the job on the original schedule, resubmit the start_time desired using ctxjsub.sql.

C.7 Timing and Caching Statistics

All OracleAS Portal pages can be run in a special mode in which timing and caching information is displayed. If you want to see this debug information on every page you can set the Parallel Page Engine Parameter showPageDebug to true in the web.xml file.

See Also:

Appendix D, "Configuring the Parallel Page Engine".

If you want to see the debug information for just a few select pages and portlets, you can control the logging level by the _debug URL parameter. For example, to see the timing statistics for the following OracleAS Portal page: 

http://abc.com/servlet/page?_pageid=21

You can manually insert &_debug=3

To make: 

http://abc.com/servlet/page?_pageid=21&_debug=3

Possible values for _debug are 0, 1, 2, 3, 4, and 5.

Values greater than 1 will potentially raise the logmode value for the duration of the request, and trigger all request log messages to be echoed into the page response.

Note:

All values greater than 0 cause _debug=1 to be propagated in back end requests.

Table C-3 shows the results of _debug values:

Table C-3  _debug Values for Timing and Caching Statistics
Value Timing and Caching Statistics? Flag Forwarded to Providers? (as value 1) logmode Raised to a Minimum of Log Messages Written to Page Response?

0

Yes

-

-

-

1

Yes

Yes

-

-

2

Yes

Yes

debug

Yes

3

Yes

Yes

request

Yes

4

Yes

Yes

content

Yes

5

Yes

Yes

parsing

Yes

urlDebugMode and urlDebugUsers are additional parameters that can be used to restrict the use of _debug on a URL. See Appendix D, "Configuring the Parallel Page Engine" for more information.

The following statistics are available when the portal page is run in debug mode:

The following image shows a page that is running in the _debug=0 mode:

Figure C-1 Portal Page Running in Debug Mode

Text description of cg_sshot_dbug.gif follows.

Text description of the illustration cg_sshot_dbug.gif

C.7.1 Portlet Statistics

In Figure C-1, you can see a number of Portlet related statistics listed under each portlet. Each Portlet has a unique internal reference identification number. This number is used in the "Information for Portlet" summary. For the portlet in the top left corner of Figure C-1, you can see that this number is 6256.

For each portlet the following statistics are listed:

C.7.1.1 Portlet Timing Information

C.7.1.2 Portlet Caching Information

C.7.2 Page Statistics

Every page has a unique internal reference identification number, similar to the portlets on the page, shown in Figure C-1.

For the page, the following statistics are listed:

C.7.3 Additional Summary Statistics

C.8 Using the cfgiasw Script to Configure Mobile Settings

If you want to change Portal's references to OracleAS Portal or Oracle Application Server Wireless' Portal service URLs, you need to use the script cfgiasw.csh (UNIX) or cfgiasw.cmd (Windows) to manually update the references. The script files are located here: 

ORACLE_HOME/assistants/opca/

Running the script without parameters will print its usage to the screen, which is shown next:

Usage: 

cfgiasw.csh -s portal_schema -sp portal_schema_password 
     -w ias wireless url 
     -h portal home page url 
     -c connect_string
Table C-4  Oracle Application Server Wireless Configuration Parameters
Parameter Description

-s

Oracle Database schema for OracleAS Portal database objects.

Default = PORTAL

-sp

Password for the OracleAS Portal schema.

Default = portal_schema

-w

The URL of the Oracle Application Server Wireless gateway for mobile requests to OracleAS Portal. This parameter is not mandatory (no default).

-h

The URL of the OracleAS Portal home page. This is used within Portal to determine the character set of the Portal middle-tier. This information is required when creating an Oracle Application Server Wireless service This parameter is not mandatory (no default).

-c

Connect string for database (no default).

For non-hosted Portals, the Oracle Application Server Wireless' Portal service URL reference can be set in the Mobile tab of the Global Settings page, except the URL of the OracleAS Portal home page, which can only be set using the cfgiasw script.

This script is used to set references to both the Oracle Application Server Wireless Portal Service URL and the OracleAS Portal home page URL, in OracleAS Portal. It can be used in a hosted environment to set the URL references, and will affect all subscribers, because this information is not configured separately for each subscriber.

For example: 

cfgiasw.csh -s portal -c portal_db -w 
'http://iaswhost:port/ptg/rm?PAoid=%%wireless_service_id%%'

In the preceding example, if a mobile device makes a request to the OracleAS Portal directly without being mediated by an Oracle Application Server Wireless server, OracleAS Portal redirects the client to the URL specified here. This URL should be the OracleAS Portal's service URL on the Oracle Application Server Wireless server, in the form: 

http://<host>:<port>/ptg/rm?PAoid=<service_id>

If this setting is blank, then mobile client requests made directly to OracleAS Portal receive an HTTP status indicating that their request is not supported.

For configuring other mobile settings in OracleAS Portal, see Section 14, "Click OK.".

C.9 Using the ptlinvsw.sql Script to Invalidate Portal Container Pages

If a user navigates to a sub-page within a page portlet and edits it, the changes are not visible immediately unless the page containing the portlet is invalidated by other means.

Session store lookup helps solve this issue. When a page is edited, the session store is first looked up to determine all the pages that have a portlet which is currently displaying the edited page, and then those pages are invalidated.

Since the session store lookup affects performance, this feature is not enabled by default.

To enable Portal container page invalidation:

  1. On the database where the Portal schema is installed, navigate to the ORACLE_HOME/portal/admin/plsql/wws directory.

  2. Log on to SQL*Plus with the appropriate user name and password for the Portal schema.

    For example: 

    sqlplus portal/portal
  3. Enter the following command: 

    SQL> @ptlinvsw.sql TRUE

    To disable this invalidation option, enter the following command: 

    SQL> @ptlinvsw.sql FALSE

Go to previous page Go to next page
Oracle
Copyright © 2002, 2003 Oracle Corporation.
All Rights Reserved.
Go To Documentation Library
Home		 Go To Product List
Solution Area		 Go To Table Of Contents
Contents		 Go To Index
Index