Back to top

Template Modifications Required

Every attempt is made by the patch installer to both preserve customized template information and automate the update of that information. However, since the contents of the files cannot be accurately predetermined, any modified template files are backed up in the same directory as their updated counterparts with the patch name postfixed to the template name. For example, /etc/opt/SUNWps/desktop/default/MyFrontPageTabPanelContainer \ /Netlet/display.template might be backed up to /etc/opt/SUNWps/desktop/default/MyFrontPageTabPanelContainer/ \ /Netlet/display.template.pre . The backup files are also copied back to their original location upon patch removal. To help avoid potential content-related customization problems, refer to the Tips for Customizing Templates section of this document. The following template files, .properties files, jsps, xml files, and platform files are modified by this patch consolidation:

Back to top

Tips for Customizing Templates

Because the Portal Server itself is so customizable, you should follow some precautions to insure that any customizations made to the Portal Server are preserved after a product upgrade. First, set up a customized template directory if you have not already done so. While this directory could be an entire subset of the default template directory, it is advisable to only copy over those template files that you will be customizing. This particular scheme would then use the default directory as a 'base' for all templates and would help insure that customized templates are not accidentally overwritten when the default templates are modified.

NOTE: Files in the default template directory should should never be customized.

As a general rule of thumb, avoid modifying templates that have only a functional purpose rather than a look and feel purpose. One example of a template that should not need modifications is the NetletProvider/display.template . This template contains only JavaScript necessary for the launching of the Netlet. The contents of the Netlet Pop-up window should instead be customized by modifying the associated .properties file. The reason for this is that there could be a functional change in the product that would overwrite a customization done specifically to that particular template file. This example also exhibits why it is important to only keep customized files in the customized template directory.

Back to top

Checking the Current Product Install Level

Portal Server 6.1PC1 makes changes to both the gateway, and version scripts necessary to print additional information about the current install level. In previous versions of Portal 6, this information had to be gathered from a variety of sources including the package versions, patchadd -p output, or from a flatfile that was not updated by patches themselves. Beginning with 6.1PC1, Portal patches will now update the version files when they are installed and again when they are backed out.

To get the version information for the Gateway node, from node itself as root, type:

# /etc/init.d/gateway version
Thu Jun 19 14:29:46 PDT 2003 Portal Server Secure Remote Access 6.1
Mon May 24 23:18:52 PDT 2004

# <install_dir>/SUNWps/bin/version
Thu Jun 19 14:29:46 PDT 2003 Portal Server 6.1
Mon May 24 23:18:52 PDT 2004

# /etc/init.d/amserver version
Sun One Identity Server 6.0-sp1

'version')
  #check_amserver_script
  echo `/usr/bin/cat -s $VERSIONFILE`
;;

Maintaining Netlet Connections During Periods of Network Inactivity

In Portal Server 6.0 and 6.1, the Netlet Keepalive feature did not work as expected. The feature would force the Netlet session to terminate immediately when the interval was reached. This feature has been changed in Portal Server 6.1PC1 to send dummy packets during periods of no network activity to keep connections alive that may otherwise close as a result of infrastructure products like proxies and firewalls timing out the network connections. Specified in seconds, this value is generally set to something greater than 60 seconds, but less than half the value of the destop idle timer, to reduce security implications of abandoned sessions.

The Netlet KeepAlive Interval can be set using the Identity Server Administration Console. To change the Netlet Keep Alive Interval, do the following:

1. Log in to the amconsole
2. Select the Service Configuration Tab
3. Netlet the link next to Netlet Service From the SRAP Configuration subheading
4. Change the value for Keep Alive Interval on the right hand view pane
5. Select Save

Configuring Auth Level Checking in the Gateway

Authentication Level checking is a new feature that allows you to restrict the authentication methods used when accessing the portal via the gateway to a subset that you consider sufficiently secure. For example, you may allow users to authenticate using LDAP, Safeword, NT and Certificate authentication when accessing the portal directly, but wish to insist upon either Safeword or Certificate authentication when accessing via the gateway.

Every Authentication Service in Identity Server has an "Authentication Level". This is an arbitrary positive integer of your choice, and is 0 by default for all. By specifying a higher value for more trusted authentication services, you can restrict gateway access to those with an "Authentication Level" above a certain threshold.

Using the above example, you would set the Authentication Level for Safeword and Certificate authentication to 5 as follows:

1. Log in to the amconsole
2. Select the Service Configuration Tab
3. Expand the link next to Safeword
4. From the righthand viewpane, change the value for Authentication Level to 5
5. Repeat steps 3 and 4 for Certificate
6. Select Save
7. On the Gateway node, edit the platform.conf file for the instance(s) you wish to enfoce the new authentication policy
8. Change the value for gateway.min_auth_level to 5
9. Restart any modified gateway instances

Rewriting ID Attribute Values Contained in Form Data

Prior to Portal Server 6.1 PC1, form data that needed to be rewritten could only be matched using the NAME attribute. The NAME attribute may also be complemented or superceded entirely by an ID attribute values in some web applications. To rewrite form data that contains ID attirbute values, simply specify the ID value in the name field of the rule entry. For example, to rewrite the following form data:

<input type="hidden" id="FORM1" value="/form2.html">

<Form source="*" name="FORM1">

Rewriting JavaScript Object Property Values

JavaScript Object properties can now be rewritten as EXPRESSION rule types. For example, to rewrite a JavaScript object property similar to one used by an SAP application:

<html>
<body BGCOLOR="#FFFFFF" TEXT="#000000">
<script>
ur_system = {doc : window.document , mimepath :"/irj/portalapps/com.sap.portal.themes.lafservice/themes/portal/sap_standard/common/"};
</SCRIPT>
</body>
</html>

<Variable TYPE="EXPRESSION"> mimepath </Variable>

How to Attach Localized Files Using Netmail Lite

Prior to 6.1 Patch Consolidation 1, Japanese files could not be attached from the Compose Message window of NetMail Lite when the Attach File button is selected. A blank page would be displayed instead. 6.1 Patch Consolidation 1 solves this problem by obtaining the charset using the Portal client detection module. In order to take advantage of the fix then, client detection must be enabled, and the proper character set needs to be set for the japanese locale.

Enable the client detection module in the Portal Server:

1. Login to the Identity Server administration console
2. Select Service Configuration
3. Expand the link next to Client Detection under the Identity Server Configuration section in the lefthand viewpane
4. Select the checkbox next to Client Detection Enabled
5. Select Save

Add the necessary charsets:

1. From the Client Detection view pane, modity the Client Types Field to include localized charsets clientType=MSIE|userAgent=Mozilla/4.0|contentType=text/html|cookieSupport=true|fileIdentifier=html|filePath=html| \ charset=UTF-8|charset_ja_JP=EUC-JP|charset_zh_CN=gb2312|charset_fr_FR=iso-8859-1|charset_zh_TW=Big5|charset_ko_KR=EUC-KR
   clientType=genericHTML|userAgent=Mozilla/4.0|contentType=text/html|cookieSupport=true|fileIdentifier=html|filePath=html| \ charset=UTF-8|charset_ja_JP=EUC-JP|charset_zh_CN=gb2312|charset_fr_FR=iso-8859-1|charset_zh_TW=Big5|charset_ko_KR=EUC-KR
   clientType=NSCP_UNIX|userAgent=Mozilla/4.0|contentType=text/html|cookieSupport=true|fileIdentifier=html|filePath=html| \ charset=UTF-8|charset_ja_JP=EUC-JP|charset_zh_CN=gb2312|charset_fr_FR=iso-8859-1|charset_zh_TW=Big5|charset_ko_KR=EUC-KR
   clientType=MSIE6|userAgent=Mozilla/4.0|contentType=text/html|cookieSupport=true|fileIdentifier=html|filePath=html| \ charset=UTF-8|charset_ja_JP=EUC-JP|charset_zh_CN=gb2312|charset_fr_FR=iso-8859-1|charset_zh_TW=Big5|charset_ko_KR=EUC-KR
   clientType=NSCP_WIN32|userAgent=Mozilla/4.0|contentType=text/html|cookieSupport=true|fileIdentifier=html|filePath=html| \ charset=UTF-8|charset_ja_JP=EUC-JP|charset_zh_CN=gb2312|charset_fr_FR=iso-8859-1|charset_zh_TW=Big5|charset_ko_KR=EUC-KR
   clientType=NSCP6|userAgent=Mozilla/5.0|contentType=text/html|cookieSupport=true|fileIdentifier=html|filePath=html| \ charset=UTF-8|charset_ja_JP=EUC-JP|charset_zh_CN=gb2312|charset_fr_FR=iso-8859-1|charset_zh_TW=Big5|charset_ko_KR=EUC-KR
   
   NOTE: The leading \ preceeding charset=UTF-8 represents a line wrap and is included in this document for readability purposes only. In the Client Type field, this character should not be present, nor the whitespace padding around it.

Modify the charset properties in the psNetMailServlet properties file:

1. Edit <install_dir>/SUNWps/web-src/WEB-INF/classes/psNetMailServlet_<locale>.properties
   
   NOTE: Replace install_dir and locale with the appropriate values. Locale in this case might be ja, and install_dir might be the default /opt.
2. Change Encoding=Q to Encoding=B
3. Change iwtNetMail-charset from ISO-8859-1 to the appropriate value indicated in the Client Types Field above. For example, for Japanese locale, this should be changed to ISO-2022-JP.
4. Redeploy the portal web service by using deploy:
   <install_dir>/SUNWps/bin/deploy -redeploy -is_admin_password "<passwd>"

Back to top