Release Notes |
The Release Notes for iPlanet Portal Server, Version 3.0, Service Pack 5 document important information available at the time of release. Installing this product updates the iPlanet Portal Server software to include fixes from Service Pack 1, Service Pack 2, Service Pack 3, Service Pack 3a, and Service Pack 4 and Service Pack 5. The information in this document includes documentation for previous service packs.
These release notes contain the following sections:
Read this document before you begin installing Service Pack 5. For an online version of this and other Portal Server 3.0 documentation, see the iPlanet documentation Web site at:
After you install and start using iPlanet Portal Server 3.0, Service Pack 5, check this Web site periodically to view the most up-to-date documentation.
This section provides details about this document. It contains the following topics:
Table 1 is a three column table that describes the typographic conventions used in this release note. The first column describes typeface or symbol, the second column describes the meaning, and the third column provides an example of how the typeface is used.
Table 2 is a two column table that lists the machine names used in code examples and the types of iPlanet Portal Server components to which they correspond. The first column of the table contains machine names, the second column states what component is installed on the machine.
Machine Name
Running as . . .
iPlanet Portal Server not being used as the profile server in multiple server installations
This section summarizes the newest enhancements implemented in Service Pack 5.
See the "Desktop and Provider Changes" section of this document for details on these changes.
See the "Gateway Changes" section of this document for details on these changes.
See the "NetFile Changes" section of this document for details on these changes.
See the "Netlet Changes" section of this document for details on these changes.
See the "Performance and Tuning Changes" section of this document for details on these changes.
See the "Profile Service Changes" section of this document for details on these changes.
See the "Documentation Updates" section of this document for details on these changes.
This section summarizes the cumulative enhancements implemented in the following previous Service Packs: iPlanet Portal Server 3.0, Service Pack 1, Service Pack 2, and Service Pack 3a, and Service Pack 4.
See the "Authentication Changes" section of this document for details on these changes.
See the "Desktop and Provider Changes" section of this document for details on these changes.
See the "Gateway Changes" section of this document for details on these changes.
See the "Localization Changes" section of this document for details on these changes.
See the "NetFile Changes" section of this document for details on these changes.
See the "NetFile Changes" section of this document for details on these changes.
See the "Netlet Changes" section of this document for details on these changes.
See the "Performance and Tuning Changes" section of this document for details on these changes.
See the "Profile Service Changes" section of this document for details on these changes.
See the "Server Changes" section of this document for details on these changes.
See the "Third-Party Software Changes" section of this document for details on this change.
See the "Webmail Changes" section of this document for details on this change.
This section provides details about authentication changes in iPlanet Portal Server. It contains the following topics:
The goto parameter is now available. It enables applications to instruct authentication to redirect the user to a URL other than the default URL stored in the user profile upon login or logout. It is valid for the current session only, and it does not change the default URL stored in the user profile.
To be redirected to a specific URL, the application must specify the goto parameter in the URL.
The goto parameter allows the calling application to specify where the user is redirected upon successful login.
For example, if an application wanted to redirect the user to my.sesta.com after successful authentication, the URL would be:
http://server1.domain:port/login?goto=http://my.sesta.com
An API developer can use the goto parameter in conjunction with the logout URL to specify where the user should be redirected upon logout.
For example, if an application wanted to redirect the user to sesta.com after logout, the logout link would be:
http://server1.domain:port/logout?goto=http://sesta.com
Authentication chaining can provide a higher level of security for organizations by requiring users to authenticate against more than one authentication mechanism. For example, if the membership and UNIX authentication modules are chained, Desktop users would authenticate against both to access the Desktop.
To set up authentication chaining, complete the following steps:
The user's default URL can now be set in the pluggable authentication interface, without changing the default URL in the user's profile. When the user authenticates successfully, the user is redirected to this URL.
A new method called setDefaultURL in the pluggable authentication API allows the authentication modules to set the user's default redirect URL on successful authentication:
To use this, replace the setDefaultURL parameter with the user's default URL. This is an example of setting the default URL to www.sesta.com:
public void setDefaultURL("http://www.sesta.com")
Tip
This method overrides the goto parameter. See "Using the goto Parameter."
Portal Server now contains a membership authentication module that is useful for open portal installations. Combined with anonymous user, unregistered users can view non-personalized content in a portal, and registered users can log in and view personalized content.
The addition of a login channel on the Desktop allows registered users to access the portal, register and receive personalized pages. It allows non-registered users to view static content.
The login channel also allows the user to enable persistent cookies, if the domain allows this option. Persistent cookie support puts user login information into a cookie so that the user does not have to log in for subsequent sessions.
The user interface for the login channel does not have an edit page, as user-editable preferences are not available.
In a typical anonymous installation, the anonymous authentication module would be the only authentication type enabled. When the URL http://server.domain:port/login/domain is specified, the user's browser displays the anonymous user Desktop. No user input, other than the URL, is required.
A list of user IDs authorized to log in to the anonymous user's Desktop can be specified and modified through the administration console.
When a user ID appears in the List of Anonymous Usernames, access to the anonymous user's Desktop is granted. The session is assigned to the specified userID. When user ID does not appear in the List of Anonymous Usernames, the session is assigned to the user ID specified in the Default Anonymous Username field and the anonymous Desktop is displayed.
To change the default anonymous user name, complete the following steps:
To define the default anonymous user name, complete the following steps:
Use the administration console to enable an anonymous Desktop using the Anonymous Authentication Module and Login Channel.
To enable the anonymous Desktop, complete the following steps:
Portal Server is now defaulted to the Anonymous authentication module in all cases and displays the anonymous Desktop by default.
This enables users to use the login channel to use Membership authentication instead of having to use the provided membership login page.
You can customize templates for the anonymous Desktop by editing the menubar.html file and changing settings in the administration console.
To customize a user logout from the Desktop redirect to the anonymous user Desktop, complete the following steps:
Use this format to set the logout from the Desktop to be redirected to the anonymous Desktop in all cases:
Tip
To customize the Help page for the anonymous Desktop, complete the following steps:
The default English locale value in Front Page Help is assumed to be relative from the /opt/SUNWips/public_html/docs/en_US/online_help directory.
To create an anonymous user for any other domain, complete the following steps:
To disable anonymous Desktop, complete the following steps:
The login channel can be modified to work with other authentication modules. A sample template is available to illustrate how the login channel can be changed to work with the Unix authentication module, rather than the Membership authentication module.
To enable Unix authentication for the login channel, complete the following steps:
When replacing files to modify the operation of the Desktop, make copies of the files being replaced, first, so that they can be reinstated at any later date.
Note
The login channel now uses UNIX authentication.
The template file, display_iwtAuthUnix.html, is an example of how templates could be created to enable other authentication modules for the login channel. The contents of the built-in login page for a given authentication method provide an example of the correct parameters to include in the display.html template.
When a registered user authenticates from the anonymous Desktop, Portal Server obtains information about the user and presents the user Desktop from the user profile. When a new user registers from the anonymous Desktop, the user's current session from the anonymous Desktop is destroyed before the auth module in the URL for the user's default Desktop is called.
This allows a user with a valid iPlanet Portal Server session to directly go to a login module without sending a logout URL. For example, a login channel sends the following URL to allow an anonymous user to register with the membership module:
http://server.domain:port/login/Membership?domain=/mydomain&arg=newsession
The arg=newsession parameter instructs the authentication module to destroy the current session before calling the authentication module in the URL.
Previously, if a user wanted to switch from anonymous user to registered user, it was impossible to authenticate the user using another authentication module such as the Membership module since an anonymous user has a valid session.
Users can now change their membership login passwords.
To change the membership login password, the user must complete the following steps:
Password checking is subject to the same rules as the membership authentication module. The user must authenticate via Membership for changes to the Membership password.
A user's email address can now be used as the user profile ID on the certificate. When the email address is selected, the cert auth module searches for the emailAddr field in the certificate's user subject dn field for the attribute tag emailaddr and uses its value to access the user's profile ID.
The tag emailAddr is stored in the iwtAuthCert.properties file. It can be replaced with a different value, depending on the site or the certificate issuer.
To use the email address as profile ID, complete the following steps:
Persistent cookies are now supported. If the persistent cookie mode is enabled, the user:
If the user explicitly logs out when persistent cookie mode is enabled, logging in is required on the next visit.
Note
To set up persistent cookie mode for an individual user, the user must select the Remember My Username and Password check box using the Login Channel.
Administrators can set a persistent cookie for a domain. To do this, complete the following steps:
This section provides details about Desktop changes in iPlanet Portal Server. It contains the following topics:
The patch installer attempts to preserve customized template information and to 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/SUNWips/desktop/default/iwtBookmarkProvider/display.template
/etc/opt/SUNWips/desktop/default/iwtBookmarkProvider/display.template.preSP5.
The backup files are also copied back to their original location upon service pack removal.
To help avoid potential content-related customization problems, refer to the "Tips for Customizing Templates" section of this document.
Table 3 is a three column table that lists the template files, .properties files, xml files, and platform files that are modified by this service pack. The first column of the table contains the template or flatfile names. The second column contains the component with which the template is associated. The third column describes the change to the template.
Because the Portal Server itself is so customizable, you should follow some precautions to ensure that any customizations made to the iPlanet Portal Server product are preserved after a product upgrade. First, set up a customized template directory if you have not already done so. While this directory might be an entire subset of the default template directory, it is advisable to copy over only 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 ensure that customized templates are not accidentally overwritten when the default templates are modified.
In general, 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 iwtNetletProvider/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 (install_dir/SUNWips/locale/iwtNetletServlet.properties). This is because the product might have a functional change that would overwrite a customization done specifically to that particular template file. This example also exhibits why it is important to keep only customized files in the customized template directory.
For instance, in the iPlanet Portal Server Service Pack 3 product, the Netlet launching behavior changed. Therefore, for customers who use the Netlet, and upgraded from the iPlanet Portal Server Service Pack 2 product to iPlanet Portal Server Service Pack 3, and have an entire copy of the default template directory, the functional change was not propagated to the customized template directory.
The following sections contain instructions for some simple template modifications that may help you get you started with your new customized template directory.
To modify the look of all the channels (for example, where the buttons are and how the border looks) do the following:
If you change the red background color in banner.html, you should also change the background color in the following files wherever the HTML tag attribute BGCOLOR appears:
This text can be changed in the profile store, but it is system-wide and not specific to any one domain. To change the value system-wide, do the following:
These channels are sourced from the RSS Provider and URL Scraper providers, respectively, and are examples of how the iPlanet Portal Server can pull content from other sources. The iwtIPInfo channel is simply an HTML page and a GIF file displayed by the URLScraper. The iwtSampleRSS channel is an RDF file with an accompanying GIF file. You can set up channels like this quickly for your own portal by using the Channel Wizard in the iPlanet Portal Server Administration Console.
The links and image tags for the channel buttons are generated dynamically by the Desktop, but the actual image file sources are taken from the Desktop properties file. To change the button images, do the following:
Edit the following line in userTemplate.html to change link colors for the page:
Table 4 is two column table that contains a list of templates and tag descriptions. The first column lists the template name. The second column provides a tag description.
The top level TABLE attribute definitions have been moved from being emitted directly by the FrontProvider Servlet to the userTemplate Desktop template file. All customized template directories under /etc/opt/SUNWips/desktop/ that contain an iwtDesktop/userTemplate.html file will be modified automatically by the installer to include the default TABLE attributes which were already being set by the FrontProvider.
As a result, the attributes can now be modified to provide more flexible control over the look and feel of the entire iPlanet Portal Server Desktop in addition to providing a means to use Cascading Style Sheets for themes, or JavaScript to change the TABLE attributes dynamically.
If the content tag ([tag:content]) was already removed from the userTemplate.html file prior to the service pack installation, the template will need to be updated manually in order for the portal contents to be displayed correctly.
Just below the inlineError tag ([tag:inlineError]) of each customized userTemplate.html file, add the following:
Individual channels on the iPlanet Portal Server Desktop can now be maximized. Maximizing a channel means that it is displayed on entire Desktop space between the horizontal menu bars. When a channel has been maximized, the banner and the menu bars are still visible.
If a channel is edited in the maximized state, its previous size will be restored once the edit is completed. Additionally, if the provider is detached while maximized, it will be re-attached in a restored state.This feature is also extended by adding the ability to tag-swap the providerName tag ([tag:providerName]) in the provider Desktop templates.
In order to maximize a provider channel, a URL should be constructed so that the channel's name appears at the end of the query string. The following is an example of a relative URL for a stocks channel:
/DesktopServlet?action=content&provider=iwtMaximizeProvider&targetprovider=stocks
Selecting this link from anywhere on the Desktop or explicitly setting it in the URL field of the web browser, after being fully qualified, will result in the stocks channel being maximized.
This maximize feature differs from the maximize functionality already built in to the Desktop as a provider command. When a provider has been minimized, the menu bar for the provider will contain a maximize button. Maximize, in this instance, will merely restore the provider to its original position and size on the Portal Desktop.
One example of how to use this new feature on the Desktop would be to create the maximize URL dynamically using the tag-swapping capability of the iPlanet Portal Server from within the providerWrapper.html template. The provider commands available are determined based on the policy for that provider and user. However, a maximize button could be inserted just prior to the provider_cmds tag so each provider could be independently maximized.
In this example, default Desktop images were used for two additional buttonsone to maximize the provider, and one to restore it to its original size. To avoid potential confusion for the end users, these buttons should be made unique if the providers will be allowed to minimize or detach.
Both the providerWrapper.html and userTemplate.html files could be changed to have only one image which would represent the current state of the provider (maximized or restored).
Add the following to the HEAD element of the userTemplate.html file:
Edit the providerWrapper.html template to look like the following:
The preceeding example uses JavaScript to determine whether the provider is maximized or not and to dynamically update the button and corresponding URL.
The Netscape Navigator 4.x browser does not correctly update the ALT text of the image object. For example, the ALT text for the restore button will say "maximize."
Note
This example demonstrates how the provider maximization feature might be generally applied to the Desktop. Many other applications are possible. If Secure Remote Access Pack has been installed, verify that any reference to the maximize or restore URLs are rewritten correctly.
The JSP Provider allows you to use JavaServer Pages technology to write providers for Desktop channels. JSP Provider-based channels have the following attributes in addition to the attributes of other channels:
The contentPage and editPage JSP specifications can be used in various combinations. For example, you can use a JSP specification to generate content while you can use Java code in the provider class to generate the edit page. Both have access to iPlanet Portal Server platform services.
Processing of the edit form consists of Java code that checks validity of the form entry and updates user preferences for the channel. The result is a display of the Desktop in the case of success or a display of the edit page in the case of a failure, possibly with some error information for the user.
To handle the processing of an edit form, the JSP-based provider has these options:
Support for JSP-based channels is provided through a class called JSPProvider. The JSPProvider extends the ProfileProviderAdapter class to support other attributes for the channel by using the profile service.
When specifying a JSP in one of the JSP attributes, the path name is interpreted relative to the Desktop template directory using the same algorithm as for other Desktop templates, including the locale setting.
If the user's locale is de_DE, the Desktop type is SunBlue, and a JSP attribute is set to myChan/chan.jsp, the system would search for these JSP files:
/etc/opt/SUNWips/desktop/SunBlue_de_DE/myChan/chan.jsp
/etc/opt/SUNWips/desktop/SunBlue_de_DE/chan.jsp
/etc/opt/SUNWips/desktop/SunBlue/myChan/chan.jsp
/etc/opt/SUNWips/desktop/SunBlue/chan.jsp
/etc/opt/SUNWips/desktop/default_de_DE/myChan/chan.jsp
/etc/opt/SUNWips/desktop/default_de_DE/chan.jsp
/etc/opt/SUNWips/desktop/default/myChan/chan.jsp
/etc/opt/SUNWips/desktop/default/chan.jsp
For more information on implementing JSP-based channels, see the Javadoc software shipped with Service Pack 5.
Tip
Cookies can now be set from JSP provider channels using response.addCookie(cookie_name) to amend the Set-Cookie response from the Desktop Servlet. For example, a personal cookie-based counter could be added to the out-of-box samplecontent.jsp by adding the following code to /etc/opt/SUNWips/desktop/desktop_name/samplecontent.jsp:
When the default JSP provider channel is accessed, a cookie will now be set and the provider will indicate the cookie value plus one which represents the current number of visits to the page.
When the Desktop accesses templates to generate content, it reads them from disk and caches them. All subsequent requests for the template are served from the cache.
The Desktop periodically checks to see if the disk files have been updated. If the disk file is newer than the cache, the template is re-cached based on the updated disk file.
The length of time between checking to see if the disk files have been updated is the template scan interval. This interval can now be changed in the administration console. Changing the template scan interval causes the Desktop to immediately check for changes to the disk files and then wait for the new interval value before re-checking again.
To change the template scan interval, complete the following steps:
The default value for the template scan interval is 900 seconds, or 15 minutes.
Tip
The Desktop can now use tabs to organize content. Tabbed Desktop pages can be individually modified to customize the Desktop.
The tab feature must be turned on for any given domain. By default, it is not active. The super administrator must enable the Tab Provider and then configure or remove tabs in a chosen domain.
To enable Desktop tabs in a particular domain, complete the following steps:
name=new tab|channels=iwtTabProvider;iwtUserInfoProvider;
iwtIPInfoProvider;iwtSampleRss|desc=new tab description|
removable=true|renamable=true
name=Make From Scratch ...|channels=iwtTabProvider;iwtUserInfoProvider;
iwtBookmarkProvider;iwtIPInfoProvider|desc=Design a tab from the ground up|
removable=true|renamable=true
Users can configure the tabs on their Desktops. The tab's channel edit page allows users to create, rename, or remove tabs from their Desktops. In addition, users can select which tab should be present on the initial Desktop page.
To configure tabs, the user must complete the following steps:
In the Edit Tab Provider page, the user can use a predefined tab content template by topic, or by choosing each channel for the new tab manually.
To create custom tabs, the user must complete the following steps:
During configuration of Desktop pages and layout, the administrator uses the administration console to determine which channels are thin and thick.
Tip
To create a default content for a tab, the user must complete the following steps:
Desktop tabs can now be aligned from the left side or the right side of the Desktop. By default, tabs are left-aligned.
To use tabs, the super administrator must enable the Tab Provider and then configure or remove tabs in a selected domain.
To change to right-to-left ordering of Desktop tabs, complete the following steps:
The Provider API now allows a channel to return either a complete HTML edit form, or a subset of a complete HTML page in response to a request for the edit page.
Integer constants are added to the Provider interface that return values from the getEditType() method. These integer constants define the form type, return type, from the getEditType() method:
New methods query and set the form type.
The Desktop uses the getEditType() method so that it knows to expect either a complete or subset HTML form to be returned when calling channel.getEdit().
These restrictions apply to what can be returned from getEdit() when the edit type is equal to EDIT_COMPLETE:
For channels that extend the ProfileProviderAdapter class, a new attribute can be defined in the profile component:
The default value is different for each provider. Variations to this might include turning off write permission for OWNER, if one or the other edit type was not implemented.
All iPlanet Portal Server default channels return Provider.EDIT_SUBSET. Modifying the -editType attribute causes a malfunction. A new channel must return Provider.EDIT_SUBSET, or Provider.EDIT_COMPLETE depending on how the getEdit() method is implemented.
Administrators can now lock a channel's position so that the user cannot change its position or remove it from the Desktop. The purpose is to force the user to see particular content.
The Layout page that allows the user to arrange channels on the Desktop does not list locked channels.
To lock a channel's position, complete the following steps:
If you select the Movable check box, the user can move channels around in the Desktop.
Tip
If you select the Removable check box, the user can remove channels from the Desktop.
Tip
To unlock a channel's position, complete the following steps:
If you select the Movable check box, the user can move channels around in the Desktop.
Tip
If you select the Removable check box, the user can remove channels from the Desktop.
Tip
The Portal Server Desktop can now display full-width channels. A full-width channel spans the width of the Desktop, either at the top or bottom.
To configure a full-width channel, complete the following steps:
The Portal Server Desktop can now display unframed channels. A frameless channel is one that is displayed without a title, controls, and a border or frame.
To configure a frameless channel, complete the following steps:
If the Framed? check box is selected, the channel is displayed with a title, controls, and border.
Tip
To modify just the border of the channel, edit the hasBorder attribute in the Policy page.
Note
The Login Provider Channel template files now use the POST method for improved security when submitting the login forms. This change provides the choice of using the POST or GET methods in customized login channels.
Using the POST method is more secure because it prevents the password from showing up in the server logs, URLs and bookmarks.
The URL scraper can now forward cookies passed in the HTTP request to the Desktop. That is, the URL scraper sends cookies when it makes a connection to the target site to retrieve the content it is scraping. The URL scraper also sends set-cookie requests to the browser. That is, it gets all cookies from set-cookie headers and adds them to the HTTP response to the client browser.
By default, no cookies are forwarded. For the affected domain, role or user, the administrator must use the administration console to set the list of cookies to forward.
To forward cookies, complete the following steps:
Multiple cookies containing the same name and the same path can be stored, as long as the domain is not explicitly set to the same value. By default, the domain value is the fully qualified hostname of the server that originally set the cookie.
If the cookie is in a different domain from the server (for example, if scraping a page to the iPlanet Portal Server Desktop that sets its own cookie), complete the following steps:
Use this format to add the domain name:
Note the . that precedes the name.
Tip
If the cookie is set from the same domain as the server, complete the following steps:
Providers can now access HTTP request and response headers. This change is desirable for single sign-on, setting cookies, getting parameters from the HTTP headers, and for inserting data into the headers.
Three new methods in the Content Provider interface are available to provide this. The methods are:
These methods in the ProviderAdapter and ProfileProviderAdapter classes call the getContent, getEdit, and processEdit methods.
Table 5 is a two column table that lists the indicated methods for the HttpServletRequest and HttpServletResponses objects. The first column lists the method name and the second column lists the return values.
getSession(boolean)
Null
The session time out unit of measurement is now in minutes.
To set the session time-out to the maximum possible value, complete the following steps:
NetFile and NetMail applications now work on a Macintosh similarly to the way they work on other supported platforms.
The Netlet application, when used on a Macintosh, however, does not support the dynamic loading feature. If the Netlet is enabled, Macintosh clients automatically load the Netlet when the Netlet Channel is enabled on the Desktop.
Table 6 is a two column table that lists the minimum system requirements for running the Netlet, NetMail, and NetFile applications on Macintosh clients. The first column contains the system component name, and the second column describes the minimum requirements for that component.
Component
Description
This section provides details about gateway changes in iPlanet Portal Server. It contains the following topics:
It is now possible to configure multiple gateway instances on a single system, with the following caveats:
The ipsgateway script in install_base/SUNWips/bin now supports several new options. Table 7 is a two column table that describes the new ipsgateway command options. The first column contains the command, and the second column provides a description of the new command.
The following examples assume that the commands are being run from the directory in which they reside.
Command
Description
Adds a new gateway instance listening on fully_qualified_instance_name
Deletes the instance listening on fully_qualified_instance_name
In addition, the following commands in install_base/SUNWips/bin now accept an optional instance name argument to specify the instance to target:
The instance created at install time is considered the default instance, and is addressed using the above commands with no hostname argument. The default instance cannot be deleted.
There is also a copy of the ipsgateway script in the /etc/init.d directory.
The gateway instance name must be the fully qualified hostname in DNS for the IP address to which this instance will bind.
Note
You can create multiple instances of the iPlanet Portal Server gateway, after you install the iPlanet Portal Server gateway.
Unless you have a multi-homed system and wish to have individual gateway instances for each physical interface, you will need to configure a virtual interface for each gateway instance to bind to. For more information on configuring virtual interfaces, refer to InfoDoc 15659 at http://www.sunsolve.sun.com.
By default, the minimum and maximum JVM heapsize value for the default instance is 512Mb and 768Mb respectively, and for additional instances is 256Mb and 384Mb respectively. If you configure a large number of instances, you may want to change these values in the ipsgateway script, to avoid exhausting physical memory.
To create a new gateway instance, perform the following steps.
After the iPlanet Portal Server gateway has been installed, and the appropriate interfaces are established, do the following to create a new gateway instance:
After creating the instance, do the following to add the instance name and default portal domain for that instance:
Alternatively, use the ipsadmin command line utility to:
The JavaScript rewriting ability has been extended to include the ability to use wildcards for rules that can be added to the Rewrite JavaScript Variables in the URLs section of the Gateway Profile. This helps reduce the number of similar rules necessary to represent the same basic JavaScript content. It also allows the creation of rules to represent complex JavaScript content that makes proficient use of the JavaScript object model where arrays are used to access data values.
Previously, if the content looked like:
document.all["IMG"+img].src = "../../images/"
The only solution would be to change the code in a manner similar to the following:
up2dir = "../../" document.all["IMG"+img].src = up2dir+"images/"
and add up2dir to the Rewrite JavaScript Variables In URLs section of the Gateway Profile.
It is now possible to define a rule such as document.all*.src in the same section of the iPlanet Portal Server Gateway Profile.
A new entry has been added to the /etc/opt/SUNWips/platform.conf file called allow.client.caching. This controls the caching behavior of non-Desktop content redirected through the gateway.
Setting allow.client.caching value to false will result in a pragma:no-cache header being set for any content retrieved by the gateway. This ensures that no Portal content accessed by remote users will be cached on their local machine, regardless of their individual browser caching options if they are using at least an HTTP 1.0 compliant browser.
For example, if the iPlanet Portal Server has been deployed to take advantage of its authentication and secure remote access features, but not the Desktop itself, setting allow.client.caching to false will prevent whatever content is redirected after successful authentication from being cached on the user's local machine.
Setting allow.client.caching to false, will dramatically increase the load on the gateway component. Caching itself exists to eliminate unnecessary server requests for static content. However, in a secure environment, the performance ramifications of not allowing client caching of content may be outweighed by the added security of content not being permanently, even temporarily, stored on a remote machine. This might be the case when a remote employee is accessing sensitive corporate intellectual property from a public Internet kiosk.
Additionally, a Microsoft Internet Explorer 5.x limitation exists in which helper applications cannot load encrypted data with associated MIME types not handled internally by the browser if a "no-caching" header is set. The same is true for saving encrypted files to a different location on disk.
Internet Explorer has its own functionality for preventing the permanent caching of SSL pages. This functionality can be configured using an advanced browser setting called "Do Not Save Encrypted Pages To Disk." When this option is not enabled, Internet Explorer first decrypts the SSL data, then caches it in the clear prior to handing the decrypted copy to a helper application like Word for .doc files. This functionality is not related to the iPlanet Portal Server itself, since it affects users accessing any SSL-enabled web server in the same way. When the "Do Not Save Encrypted Pages To Disk" option is enabled, the behavior appears to be exactly the same, except the browser cleans up after itself by removing the decrypted data from the cache directory once it is handed off to the helper application.
Therefore, the iPlanet Portal Server allow.client.caching option should not be set to false if Internet Explorer will be a supported client by the deployed portal, with end users downloading or saving files locally that are not registered to be handled internally by the browser itself.
Many secure portal deployments need to work around the browser no-cache header limitation for SSL pages. Working around the browser no-cache header can be difficult if the browsers are not under corporate IT control. If the browsers are under IT control however, a custom Internet Explorer browser can be built using the Internet Explorer Administrator Kit (IEAK).
With the IEAK, the advanced browser option "Do Not Save Encrypted Pages to Disk" can be locked down in an enabled state. If the iPlanet Portal Server gateway is running https, no pages accessed by the client will be cached. This essentially works around the limitation of encrypted pages having to be decrypted and cached prior to being passed to a helper application. Such is the case when this browser option is not enabled. With the default iPlanet Portal Server platform.conf entry allow.client.caching set to true, Internet Explorer browsers can access any pages through the gateway regardless of whether they need helper applications to launch without caching any data.
To limit access and possible caching by other browsers, logic can be added to /etc/opt/SUNWips/auth/[your_template_dir]/login_template.html that disallows their login, and possibly usage.
Alternately, multiple gateways may be used with a redirector in front basing its decision on the userAgent. This would enable allow.client.caching to be set to false on one iPlanet Portal Server gateway accessed by Netscape clients and set to true on a different gateway accessed by Internet Explorer clients (customized using IEAK or with a downloaded activeX plugin that would enforce the "Do Not Save Encrypted Pages To Disk" option enabled). Because SRAP licenses are based on the number of users instead of CPUs, having multiple gateway hardware boxes will not affect software costs for the same number of users.
Using the same psuedo-code as above for an Internet Explorer-only solution, the multi-browser solution might look as follows:
Two new Gateway Profile sections have been added. They are advanced configuration options and should be used only as a last resort for difficult rewriting problems that have no other workaround.
To access these new Gateway Profile sections:
This Gateway Profile section is suitable for search, rewrite, and replace applications where JavaScript language dynamically creates HTML through multiple document.write function calls. For example:
In this particular case, the FORM tag is broken up by multiple document.writeln() function calls, and the rewriter is unable to determine that ACTION is an HTML tag attribute of the FORM tag. In order to rewrite correctly, the URL pattern ../servlet/ needs to be added to the Rewrite JavaScript Function Parameters in Fractured HTML section of the Gateway Profile.
Some JavaScript functions do not differentiate the context of what can be passed to the function as a parameter. This additional Gateway Profile section allows for some ambiguity in rewriting JavaScript function parameters. Specifically, this new Gateway Profile section allows the rewriting of JavaScript function parameters that are themselves either JavaScript or a URL. For example:
In this example, a function target has been created whose second function parameter can either be a URL or a JavaScript statement. To rewrite this correctly, Target:,y would be added to Rewrite JavaScript Function Parameters in JavaScript or a URL, instead of Rewrite JavaScript Function Parameters.
URLs that are relative to the server root are resolved using the browser's URL field or may be constructed by using built-in scripting methods created from the browser's URL field. If the request to fetch the URL contains a Referer header (such as requests for embeded images) a redirection will be created so that the browser asks for the correct, rewritten, fully qualified URL.
If no Referer header exists, a 404 not found HTTP error will be returned instead. For example, the following message will be thrown in iwtGateway logs:
By turning on message level logging and testing the gateway access to internal content with Service Pack 5, it may now be possible to use the logs as a self-help mechanism for finding things that should be added to the Gateway profile.
Gateway logging is now disabled by default because logging traffic between the gateway and the server can affect portal performance.
Administrators can use the administration console to enable gateway logging.
To enable gateway logging, complete the following steps:
In the following instructions and examples, /opt is the default installation directory.
Note
The entries in this list are the names of the JavaScript variables which are in turn expressed in JavaScript, and which is rewritten by the gateway.
The iPlanet Portal Server administration console's Gateway Profile page contains the Rewrite JavaScript Variables in JavaScript list.
If the list has the following entries:
The gateway tries to rewrite the right-hand sides of both jsvarjs1 and jsvarjs2.
The gateway wraps the matched parameters with a function called iplanet, which does the actual rewriting when the browser interprets the page.
The iPlanet Portal Server administration console's Gateway Profile page contains the Rewrite JavaScript Function Parameters Function list. This is the syntax for entries in this list:
java_script_function_name: [y|], [y|], ...
The gateway rewrites JavaScript variables or JavaScript functions according to existing rules specific to that variable, or function, in the gateway profile.
The gateway tries to rewrite the matched parameters. A matched parameter in JavaScript is either in the form of a JavaScript variable or a JavaScript function.
The iPlanet Portal Server administration console's Gateway Profile page contains the Rewrite JavaScript Function Parameters list. Each entry in the list has the following syntax:
java_script_function_name: [y|], [y|], ...
The gateway tries to rewrite func2 and var3.
Administrators can now use the administration console to edit the Rewrite Applet/Object Parameter Values list on the Gateway Profile page.
This is the syntax for entries in this list:
If the gateway receives this request for the URL:
Table 8 is a two column table that contains examples of entries for the Rewrite Applet/Object parameter Values List. The first column provides an example value that is entered in the list. The second column provides a description of how the URL is rewritten.
A new attribute allows administrators to deny unknown certificate authorities (CAs). The ips.gateway.trust_all_server_cert attribute is in the /etc/opt/SUNWips/platform.conf file. It is used when the Portal Server gateway component uses SSL to communicate with:
See "Adding a Root CA Certificate" for instructions on installing a Root CA certificate.
Tip
The default value of this attribute is false. Administrators should change the value to true to trust all CAs presenting signed certificates to the gateway component during an SSL handshake. For example:
ips.gateway.trust_all_server_certs=true
Typically, the Root CA certificate should be added to gateway certificate database so that the gateway component can identify the certificate presented. However, if a site presents a self-signed certificate, setting the ips.gateway.trust_all_server_cert attribute to true allows the iPlanet Portal Server gateway component to communicate with the site presenting the unknown certificate.
If the gateway does not recognize the certificate that is presented, and if the ips.gateway.trust_all_server_cert attribute is set to false, this error is generated:
A new parameter now allows administrators to specify the number of times the iPlanet Portal Server gateway tries to make a socket connection to a destination server should the first attempt fail. The ips.gateway.sockretries parameter is in the platform.conf file.
To specify the number of times the gateway tries to make a socket connection, edit the platf `orm.conf file in /etc/opt/SUNWips and change the ips.gateway.sockretries definition. For example:
The Outlook Web Access (OWA) 2000 application can now be used with the iPlanet Portal Server gateway component. To do so, enable basic authentication for your server.
NTLM authentication is not supported.
These attribute settings in the iPlanet Portal Server administration console are no longer used:
These settings appear in administration console on the Manage Gateway Profile page, but they do not function. The information in the "IP address validation" section in Chapter 8 "Configuring the Gateway" of the iPlanet Portal Server 3.0 Administration Guide no longer applies.
This section provides details about localization changes in iPlanet Portal Server. It contains the following topics:
The administrator can now specify the locale for domains, roles, and users. A single Portal Server installation with three locale packages installed, for example, allows the administrator to set up three domains, one for each locale. Users registering in domain1 use locale 1. Users registering in domain2 use locale2 and so on.
When you install a new locale, you must run the ipsadmin command to update the iwtPlatform attribute. The iwtPlatform-availableLocales attribute lists all the locales available for the user. For example:
Although values for this attribute are en_US or ja_JA, for example, users see only the common name of the available locale English or Japanese.
To specify the locale for domains, complete the following steps:
Users can now select their own locale from a list of locales available.
The provider displays the list of languages to the user. After the user makes a selection, it stores the selection in the user profile. The user must then log in again to get the new locale.
To select locale, users complete the following steps:
This feature allows the user to see the changes in the locale of choice.
When editing the profile, for channels created with the channel wizard in a non-English locale, the administrator now sees the choices translated in the chosen language of the locale.
A new properties file was added to localize the default Desktop's JSP Provider's title and description. The file, iwtSampleJSP.properties, is in /opt/SUNWips/locale.
This change is visible in the Desktop content provider list as the title and description and also on the Desktop channel title bar as the title.
To change the values of the JSP channel title and description, edit the iwtSampleJSP.properties file and change the description and title entries to display the desired text. For example:
Other entries in the file are used in the administration console for this provider. They are not displayed for the end user. These values align with the idx values in the attributes of the XML files.
A copy of the JSP Provider properties file is created specifically so that you can create your own JSP property file for different localizations. In the file, locale specifiers are used as suffixes for locale-specific files. For example:
When a user creates a JSP Channel using the Channel Wizard, no properties file is created for that channel. The default property file for a newly created JSP channel is the iwtJSPProvider.properties file, but this file cannot be customized.
To customize or localize the title and description of the newly created JSP channel, complete the following steps:
The entries other than title and description in this file are unused, because newly created JSP channels get their admin strings from the iwtJSPProvider.properties file. They all share the same strings and would all be edited or localized at once.
This section provides details about NetFile changes in iPlanet Portal Server. It contains the following topics:
NetFile enhancements include Internationalization compliance and features enabling broader support of FTP servers and usability enhancements. Internationalization compliance is achieved through a combination of internal modifications, and an additional modification to the end user interface. When creating a new share, there is now an option to select the system encoding type. In order to establish a successful connection, the encoding type selected by the end user must match the encoding type of the FTP server.
By applying this service pack, 15 encoding types are added to the NetFile properties files. For more information about the exact properties files entries refer to the section titled "Template Modifications."The default encoding type is ISO-8859-1, and will be associated with a system and consecutive shares if another encoding type is not explicitly selected from the drop-down menu prior to selecting OK.
The following usability enhancements have been added to make NetFile easier and more intuitive to use:
File Transfer Protocol (FTP) support for NetWare File Systems through the NetFile and NetFile Lite applications is now available.
The administrator uses the administration console to add a NetWare File System to NetFile applications. This allows users to use NetFile in the same way they do for any other host type.
To add a NetWare File System, complete the following steps:
The administrator uses the administration console to add a Novell file system to NetFile Lite applications. This allows users to perform NetFile functions by using the check boxes next to the file names and selecting an action using a button at the bottom of the page.
To add a Novell file system, complete the following steps:
Administrators can now define Systems and Shares for NetFile and NetFile Lite at the domain, role and user levels. By setting common host data attributes, administrators can define systems and shares to be displayed in the end user's Network Neighborhood.
These NetFile profile attributes changes were made to allow this:
To define Systems and Share at the domain level, complete the following steps:
Applying changes to subroles may overwrite customizations done further down the tree, for example, at the user level.
Note
To view the defined systems or shares in NetFile, the end user must complete the following steps:
To define Systems and Share at the role level, complete the following steps:
End users cannot delete defined hosts and shares, even if they remove them and choose to save their session upon exit.
Note
To view the defined systems or shares in NetFile, the end user must complete the following steps:
To define Systems and Share at the user level, complete the following steps:
End users cannot delete defined hosts and shares, even if they remove them and choose to save their session upon exit.
Note
To view the defined systems or shares in NetFile, the end-user must complete the following steps:
Administrators and Desktop users can now define NT hidden shares for use in NetFile. The Common Host Data attribute allows administrators to define NT hidden shares through the administration console.
The procedure for defining hidden shares through the administration console is the same as that for defining regular shares. Desktop users can add hidden NT shares the same way they would add a regular share, as long as they use the correct user name and password for the hidden share.
For administrators and user instructions, see "Defining Systems and Shares at the Domain Level."
Windows NT shares in NetFile are now alphabetized. Because all shares on a Windows NT system are automatically displayed when a user selects a system name, alphabetizing the list of shares makes locating the desired share easier.
Several NetFile enhancements now make NetFile easier to use. These include the following:
This section provides details about Netlet changes in iPlanet Portal Server. It contains the following topics:
The Netlet can now make use of the browser's Automatic Proxy Configuration file. This feature is supported in Netscape and in Internet Explorer with the Automatically Detect Proxy Settings option deselected. A valid PAC file must be specified in the configuration URL for either browser.
In Netscape, the PAC file location can be set by doing the following:
In Internet Explorer, the PAC file location can be set by using one of the following procedures.
If you are using a dial-up connection:
If you are using a LAN connection:
Internet Explorer can also make use of an auto configuration file. If end users are using INS files for autoproxy purposes, it must contain an entry for AutoConfigJSURL for the Netlet to read the proxy settings correctly. An example INS file section might look like:
An automatic proxy configuration file is written in JavaScript and defines a single function called FindProxyForURL that determines which proxy server, if any, the browser should use for each URL. Since the Netlet only needs a communication path back to the iPlanet Portal Server gateway, this decision needs to be made only once. The simplest PAC file is the one that only returns DIRECT (meaning no proxy should be used). The easiest way to test whether the Netlet is configured correctly to use PAC files is to create a simple PAC file and test it on one of the default dynamic Netlet rules, such as telnet.
This PAC file can be placed on a WebServer that is configured to send a MIME type of application/x-ns-proxy-autoconfig for the file extension pac.
Once that is done, the URL to the PAC file can be configured in the browser by using one of the procedures in "Setting the PAC File Location." and the telnet Netlet rule can be launched from the Netlet Provider. The Proxy Server used is displayed in the Java console.
The session timeout value can be set to determine session time outs in one of the following ways:
An entry called netlet.session.extension has been added to the platform.conf file. The netlet.session.extension entry can take a value of true or false.
Because of the inherent client/server relationship in most Netlet tunnels, an additional enhancement has been added that enables administrators to configure whether client-bound traffic should be considered when extending the portal session if the netlet.session.extension value is set to true. This option was previously located in the platform.conf file, where it was specified in an earlier patch as netlet.session.extension.for.clientbound.traffic. This option has moved to an Advanced Option in the Portal Server console Gateway Management screen.
The option can be changed as follows:
Enabling this option updates the iPlanet Portal Server Desktop idle timer even if the traffic is only initiated by the Netlet client's own server. Disabling this option updates the Portal Desktop idle timer only if there is activity initiated by the Netlet client itself. The implementation of this particular option depends on the definition of an Active Netlet User for any given portal deployment. As a rough guideline, here are two examples:
If the active Netlet user is defined as a real person acting in real time with the Netlet client, the Extend Portal Session for Clientbound Netlet Traffic option should be disabled. This prevents the Portal Session from being extended in the end-user's absence if the server continues to send updates or other notification to the client application.
Conversely, if an active Netlet user is defined as a real person interpreting Netlet client data pushed from a server application, the Extend Portal Session for Clientbound Netlet Traffic option should be enabled. With this definition, an end user interpreting data streamed or pushed to the Netlet client does not suddenly and unexpectedly have their Netlet session terminated as a result of the Portal Desktop idle timeout.
The new attribute's associated XML looks like:
The Netlet now supports an unlimited number of connections per Netlet. This rule change is beneficial if an application running through the Netlet requires many connections per Netlet.
Secure remote FTP transfers from an end user system to an FTP server are now provided through a Netlet connection. Without a user name, an FTP URL is interpreted as an anonymous FTP connection.
Administrators can use static or dynamic Netlet rules to set up FTP service to a single FTP server. Static rules define the FTP server that is used to transfer files. Dynamic rules allow the user to specify the FTP server.
Table 9 is a three column table that describes netlet rules and provides their formats. The first column describes the purpose of the Netlet rule. The second column states what type of rule it is. The third column provides the format for writing the rule.
Purpose
Type
Format
Rule in which the user logs in to the FTP server as an anonymous user
Rule in which the user logs in to the FTP server with a user ID
This Netlet enhancement requires creating a Netlet rule that listens for FTP requests. To create a static FTP Netlet rule for the Default Role, complete the following steps:
The Netlet proxy is used for these reasons:
To configure the Netlet proxy, complete the following steps:
To determine whether the port desired is available and unused, enter this command from the command line:
Tip
Administrators can use the command line interface to configure an automatic restart of the Netlet proxy whenever the system server is rebooted.
To start the netlet proxy automatically when the machine is rebooted, execute these commands as root:
These steps do not automatically start the netlet proxy when you use ipsserver start to restart iPlanet Portal Server.
Note
Administrators can now change the contents of Netlet windows by editing the files that store the values for these messages.
To change the message displayed in the interim status window that lets the user know when the Netlet has finished loading, modify the nc3 value in the install_dir/SUNWips/locale/iwtNetletServlet.properties file. For example:
To change the message displayed in the status window when a static rule has been defined for the current user, modify the Netlet-Provider-wait value in the iwtNetletProvider.properties file. For example:
To change the messages displayed when a Macintosh client attempts to use an automatic proxy configuration file, or when the Netlet cannot determine the Macintosh browser's proxy settings, modify values in the iwtNetletApplet.properties file. For example:
ppd.2=Netlet was unable to determine your browser proxy port setting.
ppd.3=Please enter your browser Proxy Port setting below:
pwarn.3mac=Netlet was unable configure your browser proxy settings. In your browser's Preferences->Network->Proxies section:\n\n - add these entries to the 'List of sites that you want to connect to directly':\nlocalhost\n\127.0.0.
To change the message displayed when the Netlet is started from a link within the Netlet channel itself rather than being launched following a successful login, modify the iwtNetletServlet.properties file. For example:
The nc4 value and the contButton value are displayed in the intermediate status window.
The Netlet applet can be used with Web browsers that are configured to use automatic proxy configuration (PAC) files. The automatic proxy configuration feature is supported in the Netscape Navigator and Internet Explorer browsers.
In addition to using automatic proxy configuration (PAC) files, Internet Explorer can also use an .ins automatic configuration file for automatic proxy services.
If end users are using .ins files for automatic proxy purposes, the .ins file must contain an entry for AutoConfigJSURL so that the Netlet can read proxy settings correctly. The value for the AutoConfigJSURL is a URL that points to a valid PAC file. For example: AutoConfigJSURL=http://sesta.com/corp.pac
This section provides details about performance and tuning changes in iPlanet Portal Server. It contains the following topics:
Tunable parameters and internal changes have been added to improve the overall performance of the iPlanet Portal Server gateway component. For detailed Bug IDs and descriptions of specific problems addressed by this service pack see the "Bugs Fixed" section.
The following changes are designed to improve performance:
The minimum and maximum JVM heap size for the gateway process is now 512MB and 768MB, respectively.
Three new /etc/opt/SUNWips/platform.conf entries have been added to control the behavior of forced Garbage Collection of the JVM heap by the gateway process.
Table 10 is a three column table that lists and describes the new platform.conf entries. The first column provides the name of the platform.conf entry. The second column lists the default value. The third column gives a description of the new entry.
When the gateway component makes a call to retrieve data from a remote site, the socket may fail to open or the request may not be handled because the remote site is under heavy load. Previously, the gateway would report a 502 error and not attempt to reconnect. An additional entry has now been added to the /etc/opt/SUNWips/platform.conf file to specify a number of retries for socket reconnection. The retry interval is fixed at three seconds, but the number of retries can be changed by setting the value of ips.gateway.sockretries, which has a default value of 3.
Netscape Security Service (JSS) version 2.8.4 to version 2.8.6 is now supported on the gateway component. This increases the number of HTTPS operations that the gateway component can sustain.
Certificates installed for the previous SSL library are automatically converted to the format required by NSS when Service Pack 5 is installed. However, certificate management for the gateway component is different from previous releases of the iPlanet Portal Server software. For more information on gateway certificate management see, "Web Server Performance."
For better performance under load, administrators can increase the value of the Maximum Thread Pool Size parameter to 500. The default value is 200.
To increase this value, complete the following steps:
A new method called Profile.loadAttributes for loading multiple attributes in one profile request is now available. It is used to pass a set of attribute names that can contain wildcards for multiple profile components.
The parameter name is attributeNames. The value is a set of attribute names that can contain wildcard characters.
The returned attribute values are cached in the profile object. This allows a subsequent call to retrieve these attributes faster, thereby improving overall Portal Server performance.
Short-circuiting for session and logging requests reduces the number of HTTP requests for logging and session services and eliminates XML parsing for these requests. This improves the overall performance of iPlanet Portal Server.
If the logging client and the logging server are in the same JVM, the HTTP connection is bypassed during client and server communication.
Likewise, if the session client and the session server are in the same JVM, no HTTP connection is needed for them to communicate.
Adjusting iPlanet Web Server parameter settings can improve the performance of the gateway component. Table 11 is a four column table that describes these parameters. The first column lists the parmeter and the associated configuration file. The second column lists the default value. The third column lists the recommended value. The fourth column provides a description of the parameter.
These configuration files are located in the install_directory/netscape/server4/https-server/config file.
This section provides details about profile service changes in iPlanet Portal Server. It contains the following topics:
By default, changes that users make to their profiles are distributed to other platform server instances using synchronization requests sent over HTTP. This ensures that any instance that has a cached copy of that user's profile updates it's cache with those changes before it needs to handle a request for that user again.
However, many large sites use load balancers in front of their platform servers that maintain sticky sessions. This ensures that the same platform server instance handles all the portal requests made during a single user session. Under these circumstances, distribution of user profile changes to other instances represents an unnecessary burden on the network.
Therefore, it is now possible to disable synchronization of user profile changes by adding the following entry to the /etc/opt/SUNWips/properties.file on each platform server:
This should only be used when load balancers that maintain sticky sessions are in use. A side-effect of this option is that an additional LDAP read of the user's profile is needed at each login to ensure cached copies are updated with changes made during sessions on other instances.
A separate profile service is now used for each Portal Server instance. The profile services are synchronized with each other to keep all modified profile data current. Previously, all Portal Server instances in a deployment used a single profile service. This was a potential single point of failure.
Profile requests originating at any Product_Name instance are now directed to the profile server of that Portal Server. Each Product_Name instance communicates directly with the Directory Server. Performance and scalability for simultaneous logins are improved because all profile requests go directly to LDAP without XML-to-LDAP overhead.
Multiple directory servers are not supported at this time.
The LDAPMonitor object now checks for LDAP connectivity. If it finds a lost connection, it removes all connections from its LDAP connection pool and lets the profile service create the LDAP connection as needed. The first profile service requesting an LDAP connection would then refill the connection pool.
Administrators can use directory.monitor.sleeptime, a new parameter in the etc/opt/SUNWips/properties.file, to define the length of the sleep interval, which is 30 seconds by default.
This is the format of the parameter:
directory.monitor.sleeptime=sleeptime_in_milliseconds
To set the interval to 40 seconds, for example:
directory.monitor.sleeptime= 40000
Tip
Two new methods called setUserSessionProperty and getUserSessionProperty in the pluggable auth API enable authentication modules to get and set properties in the user session. They allow authentication modules to communicate with channels, applications, or other authentication modules by setting session properties.
A custom authentication module may add the user password to the session, so that an application can retrieve this property, for single sign-on at a later time.
The parameter name is the property name, and the parameter value is the property value in this example:
The parameter name is the property name and this returns the property value in this example:
This section provides details about server changes in iPlanet Portal Server. It contains the following topics:
iPlanet Portal Server can now be deployed without the services of the gateway. Running without the gateway is referred to as open portal mode. One iPlanet Portal Server installation can be configured to support both open and secure portal modes.
The services presented by the open portal typically reside within the DMZ, not within the secured intranet. If a portal provides public information and allows access to free applications, using open portal mode allows Portal Server to respond faster to access requests.
Using the iPlanet Portal Server in open portal mode may improve the individual response of the portal for a large number of simultaneous users.
Tip
The following Portal Server features are provided by the gateway component and are thus not available when running in open portal mode:
If a user is restricted from either running the Desktop or adding specific channels within the Desktop, for example, this type of policy is still enforced.
For instructions on installing the iPlanet Portal Server software in open portal mode, see Chapter 4, "Clean Installation," in the iPlanet Portal Server Installation Guide.
Note
The typical public portal uses HTTP. You can now deploy a portal using HTTP over SSL (HTTPS). You can configure Portal Server to run HTTPS services during installation, or you can manually change from HTTP to HTTPS after installation.
See the iPlanet Portal Server Administration Guide for more information on using SSL.
The user accesses the server directly as though the server is configured for HTTP, but uses the URL https://server.domain instead of http://server.domain.
To update Portal Server to open portal mode following installation, complete the following steps:
The rules for logging in to the open Portal Server include the following:
In a portal setup without the gateway, this feature provides support for SSL (HTTPS) server for user registration although the sites run without SSL (HTTP).
All registrations and logins now can be directed to an HTTPS server, while all Desktop redirects are sent to an HTTP server. The iPlanet Portal Server supports this configuration by running two instances of iPlanet Portal Server. One instance runs HTTP, and the other instance runs HTTPS.
After you set up the server instances, you convert the second instance of the server to SSL. After configuring the second instance, you update user profiles to redirect users to the non-SSL server after authentication. See "Multi-Profile Server Support" for detailed information on setting up two instances of iPlanet Portal Server.
To ensure that all unauthenticated sessions on the non-SSL server are redirected to the SSL server, you must edit the platform.conf file in /etc/opt/SUNWips/ directory and then set the user profile to point to the non-SSL port on the open portal.
To do this, complete the following steps:
ips.nosession.url=https://server.domain:port/login
Replace server with the host name of the SSL server and port with the port number where the server is running. For example:
ips.nosession.url=https://server1.sesta.com:8081/login
Tip
If you have multiple iPlanet Portal Server server instances, you must edit the platform.conf file associated with each instance.
<FORM ACTION="https://server1.sesta.com:8081/login/Membership" onSubmit="return checkBlank()" MET
HOD=GET NAME="userid_form" ENCTYPE="application/x-www-form-urlencoded">
<FONT FACE="[tag:iwtDesktop-fontFace1]" SIZE="-1"><A HREF="https://server1.sesta.com:8081/login/Membership?arg
=newsession&page=1&Submit=New%20User">Sign Me Up</A></FONT>
For information about changing multiple instance servers to SSL in open portal mode, see "Changing Created Multiple Instance Servers to SSL."
Note
Some rewriting facilities that were only in the gateway profile are now available with the server. This allows administrators to configure parameters for URL scraping in open portal mode. These parameters include:
When the open portal mode is installed, the selections on the Gateway Profile page are not disabled even though most selections are disabled because no gateway is running.
To view this and observe the impact, in the administration console, do the following to access the Gateway Profile page:
iPlanet Portal Server now supports using a load balancer in open portal mode. The load balancer must support persistent connections, sometimes referred to as sticky sessions based on cookies. If the load balancer supports persistence based on a cookie name and value, this feature must be enabled.
If the Portal Server environment includes a load balancer, and a URL scraper channel that references material from a server other than the iPlanet Portal Server, that material is looked up from the server on which it sits. For example, server names in an image's URL are visible in the browser's page information window, and the browser accesses those images without using the load balancer.
The load balancer must be able to recognize the cookie on the first reply from portal. It should then continue to send all requests with that cookie name and value to that same server. Cookie persistence algorithms that do not recognize the cookie on the reply do not work, because the first and second request can end up on different servers.
If the load balancer does not support this type of cookie persistence algorithm, but it supports load balancing to specific servers based on the presence of a cookie name and value, the administrator can edit the appropriate platform.conf file to configure cookie values on each server.
Each server defines a special cookie that the load balancer is configured to recognize and always forwards requests with that cookie to that specific server. Each Portal Server instance sets this cookie along with the usual portal session cookie.
Cookies can be used to establish session persistence between some load balancers and servers in an iPlanet Portal Server installation.
To use a load balancer in open portal mode, complete the following steps:
Use this format to add the domain name:
Note the . that precedes the name.
Tip
This step is not for channels that point to external content. It is useful for portal-related content that is displayed in channels.
Note
For example, change this URL scraper channel value:
http://server1.sesta.com:8080/ipinfo.html
Tip
The profile server's protocol can be changed to HTTPS. This is the server that has the profile service running on it. See the following instructions.
In the following instructions and examples, /opt is the default installation directory.
Note
https://server1.server2.sesta.com@8080/profileservice
ips.server.protocol (for example, ips.server.protocol=https)
ips.naming.url (for example, ips.naming.url=https)
ips.notification.url (for example, ips.notification.url=https)
You can now run multiple instances of the iPlanet Portal Server on different ports. Running multiple instances of Portal Server, each with its own copy of iPlanet Web Server on the same physical machine, changes the context of iPlanet Portal Server to have multiple web servers and JVMs on the same machine.
It is possible to configure the various instances to implement SSL, giving a user the flexibility of switching to SSL mode for security on any of the iPlanet Portal Server instances. So when running in open portal mode, iPlanet Portal Server instances can talk over SSL.
Using the create command only configures new iPlanet Portal Server instances using the HTTP protocol.
Note
You can create multiple instances of the iPlanet Portal Server on different ports, after you install iPlanet Portal Server.
For installation instructions, see "Service Pack 5 Installation Notes" in the iPlanet Portal Server Installation Guide.
Tip
To configure multiple server instances, complete the following steps:
In the following instructions and examples, /opt is the default installation directory.
Note
This option is interactive. The administrator can continue to enter unique port numbers, not already in use, where multiple instances are to be created. Select Return after your last entry.
To determine whether the desired port is available and unused, enter this command from the command line:
Tip
This process takes approximately 5 minutes, depending on the machine architecture. Here is an example of what the script output and user input looks like:
Should any instances entered already exist, the following message is displayed before you are prompted to overwrite:
These instances can be directly accessed through the web browser. For example:
If the machine name is siroe.iplanet.com, and two port numbers 8081 and 8082 were configured as shown in the Step 1, and the install directory was /opt, the following files are listed:
/opt/SUNWips/bin/ipsserver.server1.sesta.com@8080
/opt/SUNWips/bin/ipsserver.server1.sesta.com@8081
/opt/SUNWips/bin/ipsserver.server1.sesta.com@8082
Table 12 lists new ipsserver commands and the command options that have been updated. The first column contains the command name and option. The second column contains a description of the command option.
The following examples assume that the commands are being run from the directory in which they reside.
In open portal mode, you can change the protocol to HTTPS of any of the other created multiple instances. Make these changes for the server where SSL is required. Make sure that the key pair file password and the trust database password entered for any of the certificate installation is the same between all the iPlanet Portal Server created multiple servers which are being configured to talk over SSL and that password must be the SSL passphrase entered during the iPlanet Portal Server installation.
In the following instructions and examples, /opt is the default installation directory.
Note
If the instance running on port 8081 is to be secure, for example, complete the following steps:
The server can now access multiple instances of iPlanet Portal Server from a single server installation. Access to Portal Server is through one of these:
To log in to a different domain on Portal Server, use this URL:
If the existing installation of Portal Server contains multiple servers and multiple domains, a URL-to-domain mapping setting allows Portal Server to find the domain automatically. The domain name does not need to be provided in the URL.
If the Portal Server installation has one server and two domains (domain1 and domain2), the following URL-to-domain mapping is needed:
To map a URL to a domain, complete the following steps:
You must repeat these steps for each domain.
Note
The domain URL list for domain1 must contain the following URLs:
In the following instructions and examples, /opt is the default installation directory.
Note
NameTrans fn="redirect" from="/domain1" url="/login/domain1"
NameTrans fn="redirect" from="/domain2" url="/login/domain2"
Replace domain 1 and domain 2 with iPlanet Portal Server domain names.
If there are three servers (server1, server2, and server3) and two domains (domain1 and domain2), the following are the URL to domain mappings:
To map a URL to a domain, complete the following steps:
The domain URL list for domain1 must contain the following URLs:
The domain URL list for domain2 must contain the following URLs:
If you write applications using iPlanet Portal Server APIs, you can run them on a server host that is not iPlanet Portal Server. The applications can be either standalone Java applications (with some limitations) or a servlet application running on iPlanet Web Server.
iPlanet Portal Server public APIs are supported only on Solaris operating systems.
Note
In the following instructions and examples, /opt is the default installation directory.
Note
To set up a non-Portal Server, complete the following steps:
A notification feature of the iPlanet Portal Server session and profile APIs allows applications to listen for profile and session state changes. If an application runs as a standalone application:
Use the administration console to reduce the cache seconds attribute in the session profile.
Tip
If the iPlanet Portal Server server is configured to use SSL, the iPlanet Portal Server APIs also use SSL. The application must also use SSL to communicate with the iPlanet Portal Server services.
The iPlanet Web Server, when installed, is not properly configured to support outgoing SSL connections by servlets.
In the following instructions and examples, /opt is the default installation directory.
Note
To enable SSL connections by servlets, complete the following steps:
To run applications using the iPlanet Portal Server gateway, you must configure the gateway to forward iPlanet Portal Server cookies to the application host. By default the gateway forwards cookies only to the iPlanet Portal Server.
If the URL of the server the application is running on is not added to this attribute, the iPlanet Portal Server cookie is not forwarded, and the application has an invalid user session.
In the following instructions and examples, /opt is the default installation directory.
Note
To configure the gateway to forward cookies, complete the following steps:
To run applications without the gateway, access the application using a fully qualified domain name (FQDN).
If a fully qualified domain name is not used, the iPlanet Portal Server cookie is not forwarded to the application, and the user session is invalid.
This section provides details about updating the smbclient command in iPlanet Portal Server.
The smb.conf parameter has been added to the smbclient command to allow NetFile to display ISO8859-1 character sets in file names.
This new parameter also provides a way for administrators to configure the NetFile application to take advantage of other smbclient features.
Here is an example of an smb.conf file that could be used to see the choices translated in a locale's chosen language:
An accompanying map file in /opt/samba/lib/users.map might look like this:
For more information about Samba-specific configurations, refer to the samba Web site at:
This section provides details about enabling Webmail applications in iPlanet Portal Server.
Portal Server can now deliver Webmail applications.
A connection handling problem between the Internet Explorer 5.5 browser and iPlanet Portal Server may result in Page not Found errors when Webmail is used. The administrator can avoid this problem by editing the Messaging Server's main.js file.
To change the main.js file on the Messaging Server, complete the following steps:
The following features and products might not be supported in future releases of the iPlanet Portal Server product:
Although the GraphOn client, Citrix software, and PCAnywhere Java client will no longer be included as third-party software with the iPlanet Portal Server product, they will continue to work with the iPlanet Portal Server product and are available from their respective websites.
This section lists known problems with iPlanet Portal Server 3.0, Service Pack 5. Details are provided in the following areas:
The text field, search filter for userId, refers to the attribute (by default, the uid attribute) to use in searching the directory. Then the attribute specified in the search filter for userId is used to create the search filter used in the lookup.
For example, if you did not specify an attribute in the search filter for userId text field and left it blank, the default is uid. So, the search filter becomes (uid=jim), where jim is the user name that the user entered. If the search filter for userId field contained the value surname or sn, then the search filter would become surname=jim.
If the Make Inherited option is selected for a field in the Administration console, the inherited value is not reflected after the change has been submitted. However the change is written back to the profile server, and will be reflected when the profile is next refreshed.
If an end user has customized the Desktop, new channels cannot be pushed to the Desktop. (4500010)
Currently, if an end user personalizes the Desktop and the administrator creates a new channel, there is no way for the channel to automatically appear on the Desktop.
Each user needs to add the new channel manually.
Adding channels using a platform server that does not have the profile server installed causes an error. (4521342)
Although the channel wizard is present in the administration console, if a platform server does not have the profile server installed, an error occurs and channels will not be added to the Desktop.
To add channels, the administrator must be logged onto the primary server (first installed server), or original profile server.
The Desktop is blank if no channels are selected in the administration console and in the Desktop. (4375670)
Workaround:
The setDomain method should attempt to retrieve a domain profile before setting the domain. (4378030)
Workaround:
The administration console allows duplicate tab names if one attribute is different. (4376634)
Workaround:
Verify that tab names are not duplicated.
The Valid Session number in the Manage User Session page provides an inaccurate number of valid sessions. (4381586)
When you log in to the administration console (either as super user or any user) and select Manage User Session, the Valid Session number is shown as 1. When you log in again from another browser, the Valid Session number does not increment to 2 to show that two valid sessions are in progress.
Contents of profilestyle.css can become visible in the administration console when adding a new user to a newly created domain. (4379326)
Workaround:
After the server is restarted, the gateway cannot be restarted from the administration console. (4531433)
After the server is restarted, the gateway's session becomes invalid. The next connection will cause the gateway to restart itself.
Manually restart the gateway and then click on the Gateway Management link again in the admin console.
Just hitting the browser reload button will not work.
Note
The gateway cannot be restarted from the administration console if a case mismatch for the gateway name occurs during installation. (4521387)
During installation of the gateway and the profile server, the fully qualified name of the gateway given should match the profile server name. For example, if gateway.sesta.com is the fully qualified name provided during the gateway installation, during the profile server installation. the gateway name must be entered as gateway.sesta.com (not gateway.SESTA.COM, for example) during the profile server installation.
if there is a case mismatch problem occurs, edit the /etc/opt/SUNWips/platform.conf file to change the ips.gateway.host value to match the entry in the server configuration. For example, change the value to ips.gateway.host=gateway.sesta.com. Then restart the gateway.
When accessing the administration console through the gateway, the URL in the browser's address field reflects the name of the server that the gateway is connecting to. The server name must be that of the primary server. If more than one instance is running on the primary server, the URL must also contain the port number for the primary instance.
The URL should be similar to the following:
https://server1.sesta.com:333/https://primary_server.sesta.com:primary_instance_port/
Remove the provider from the channel list in the Administration console.
When using Internet Explorer 5x on Windows 98, closing the Netlet window crashes the web browser. (4355280)
Workaround:
Using bookmark provider with Internet Explorer 4.x client on open portal gets a script error (4358738)
Workaround:
None. This Internet Explorer 4.x bug is not reproducible with Internet Explorer 5.x or Netscape browsers.
delAttribute permits deletion of a profile attribute without write permission. (4447005)
Workaround:
Administrators can delete their own accounts. (4454833)
Workaround:
To localize the description and title for a channel created with the channel wizard, complete the following steps:
description=This is the description
The .properties file must use Java Unicode encoding, where multi-byte characters are represented as XXXX where the Xs are hexidecimal digits.
Files in this encoding can be created from files in a variety of native encoding using the java native2ascii program.
A separate .properties file is necessary for each locale to be supported.
Note
Specify the user's character set in the profile and in the .properties file. To do so, complete the following steps:
This workaround applies for the NetMail character set and the iwtNetMailServlet.properties file. Perform this procedure for creating and editing the iwtNetMailServlet.properties file.
Note
Install Microsoft VM for Java, 5.0 Release 5.0.0.3802.
Users logged in as anonymous cannot access other authentication mechanisms with the same iPlanet Portal Server session. (4525900)
This problem requires the user to exit the browser because the anonymous user Desktop page does not have a means for logging out of the session.
Use lower case letters when setting domain names during installation and when referring to domain names.
After installation, remove the installation log file /var/sadm/install/logs/ipsinstall.process_id/install.log.
Solaris 8 patch causes patchadd -p command called from install script to fail due to large output. (4638284)
Workaround:
Change the variable assignment for AWK from usr/bin/awk to usr/bin/nawk in ipsinstall. The approximate location for this change is at line 10 in the script.
Place single or double quotation marks around the string that contains the special character to identify it as a single token.
The command ipsadmin does not check for the syntax of boolean flags. (4319514)
Workaround:
When you create an XML file, if the attribute type is boolean, add a true or false statement. For example:
If the iPlanet Portal Server software is in a non-English locale, any input provided to the ipsadmin command should be in UTF-8 character encoding when using the certain options with an xml file. (4614401)
These options include the following:
XML files should not use Java Unicode encoding as produced by native2ascii. To change the character set encoding in an XML file, do one of the following:
An example of an encoding header using the Thai character set would be:
<?xml version="1.0" encoding="TIS620"?>
An example of an encoding header set to UTF8 would be:
<?xml version="1.0" encoding="UTF8"?>
To convert an XML file to UTF8 do the following:
For example, if using Thai character set encoding, the command would look like:
For more information, see "Configuring Multiple Server Instances."
To start all processes for all instances, use the ipsserver startall command:
To start the processes for a specific instance, use the ipsserver start command and the server-specific ipsserver file:
Heavy loads for an extended duration cause components in the operating system to fail. (4472975)
Workaround:
Select some other part of NetFile to clear up the hour glass.
NetFile Lite does not check the size of a file before attempting to upload. If the file is greater than 5 MB, the upload fails. (4293370)
Workaround:
Uploading tar files greater than the 5 MB limit in NetFile Lite, and tar files greater than the 500 MB limit in NetFile generates an incorrect error message. (4372826)
Workaround:
The NetFile application allows users to access denied hosts if those hosts were added to the Desktop before a deny rule was added in the iPlanet Portal Server administration console. (4463515)
Workaround:
if Portal Server and the FTP server are on different subnets, the FTP server is tried on all the IP addresses of the interfaces. (4486094)
It is expected that the interface's IP address and the IP address of the FTP Server are on the same subnet. The solution does not work with IPv6 to IPv4 tunneling. The solution does not work with tunnelled source and destination, even if the source and destination addresses are IPv4. The solution works with multiple homes created for separating two different networks.
In the case an appropriate IP address/interface cannot be determined, the FTP server is tried for on all IP addresses of the interfaces. In this case the request can time out and NetFile would show the contents to be blank.
Wait for the reply flag to be set (slow down) or delete the message again.
IMAP password is displayed in clear text in source of edit. (4307367)
Workaround:
Add the following code inside the component tags of iwtHelloWorld3Provider.xml:
Add the following code inside the component tags of iwtQuotationProvider.xml:
During an upgrade, any custom-added attributes will be lost. This is because, if ipsadmin utility is used to add the new attributes, the utility will only add the attribute in the directory.
In order for custom-added attributes to be carried over after an upgrade, the administrator must manually add the new attributes in the associated xml file.
When attempting to upgrade individual platform servers from a multi-profile environment to a Service Pack 5 multi-profile environment, the installer assumes that Directory Server is installed locally and attempts to re-install it. (4714378)
Workaround:
Temporarily change the ips.profile.host entry in the platform.conf file from the localhost to the "real" profile FQD.
When attempting to upgrade from a highly-customized Portal Server with many new components or channels, a tuned ipsadmin script is replaced by a default script and heap space allocated for successive component imports is inadequate.
Workaround:
Modify the ipsinstall script to stop for intervention right after the SUNWwtds package has been installed. The approximate location for this change is at line 3353 in the script. Change the following lines:
Once the installer prompts you to continue, edit install_dir/SUNWips/bin/ipsadmin. The approximate location for this change is at line 34 in the script. Change the following line:
Upgrade may take a long time because custom components are imported twice, regardless of whether they differ from their XML counterparts.
Workaround:
Edit the ipsinstall and ipsadmin scripts as noted previously in this Upgrade section. In addition, once the installer prompts you to continue, remove the XML files from /etc/opt/SUNWips/xml that do not differ from values stored in LDAP.
This section lists the fixes to the known problems associated with previous iPlanet Portal Server product releases.
Table 13 is a three column table that describes the bugs that have been fixed in this release. The first column contains the Bug ID and the component with which the bug is associated. The second column provides a description of the bug. The third column lists the Service Pack number that contains the bug fix.
Bug ID
Bug Description
Fixed In
The authentication component does not use the iwtUser-defaultURL attribute value from a user's profile if the domain profile contains this attribute value.
Changes to External LDAP mappings made using ipsadmin command utility do not take effect. If new values are added to ExtLdap mapping using the ipsadmin command, the values get changed but the remote flags are not set therefore the changes do not take affect.
If Certificate authentication and SSL between the gateway and the iPlanet Portal Server are enabled at the same time, users are unable to login.
The iPlanet Portal Server returns a 502 gateway error when the administrator chooses Server Name under Session Servers.
Clicking on a server link on the Logging Servers page gives an iPlanet Portal Server gateway Error.
The attribute in LDAP to use for Profile ID field in Cert Authentication is a password field.
Administration console allows roles and users to be entered with non-ASCII characters, and generates an unclear warning message.
The Users First Name field in Membership Authentication is a password field.
The Service Pack 3 and Service Pack 3a versions limit the number of entries in the Cookie Domain List field to four. If more than four entries are used, the gateway component does not start.
Missing choice value (CVal) key value pairs in the iwtAuthCert.properties file, and spaces in the keys in the iwtAuthCert.properties file prevent some translated strings from being displayed in the administration console. Instead, the strings are displayed in the default language, which is English.
The keys in the xml files and the .properties files do not match, so some translated strings are not displayed in the administration console. Instead, the administration console displays the strings in the default language, which is English.
Domain Admin Roles page shows incorrect listing of domain administration roles.
Wrong value is inserted upon creation of CSR if a blank field exists.
The LDAP authentication module fails when iDAR is interposed between the iPlanet Portal Server and the LDAP server.
If the user logs in as anonymous, then uses the Login provider to login in, the user will not be able to use the Netlet. The Netlet loads, but the following error message is displayed: "Unable to connect to Gateway: default:443."
A series of rapid logins and logouts (100 users at 3 minutes per user session), cause the authentication servlet to fail to read the domain profile. This eventually results in an HTTP 500 server error and a fairly large memory leak.
Authentication fails when the AuthCert module cannot find the CN in an issuer name.
Authentication time out returns the error message document contains no data instead of a message stating that the session timed out.
Login channel causes passwords to show up in Web Server's access log. For more information, see "Default Login Channel Templates Changes" in this document.
Authentication chaining fails when SecureID is the second authentication module.
Authentication fails when platform server is configured to use HTTPS.
certadmin self-signed certificate validity defaults to 90 days.
UNIX authentication fails when the server and the doUnix helper are out of sync.
The option to match the certificate in LDAP does not work if the certificate in the LDAP directory is stored as binary.
The Bookmark channel should be able to take a '|' symbol in the title field. Currently, the '|' symbol is used as dilimiter and does not recognize it as a regular character. The solution is to replace '|' symbol with '-' and store the title accordingly.
The JSPProvider channel can not set a cookie at the browser.
The current implementation of the JavaScript in the bookmarks channel causes saved bookmarks to be sent through the gateway by using the "/redirect" scheme even when unnecessary.
Internet Explorer caches Desktop content. If the user logs out and then selects the back button the Desktop is displayed. The links will not work, but the contents are visible.
If a bookmark is added with the same title and same URL as an existing one, it causes a server error.
The Tab edit button is displayed on the Desktop even when the Tab Provider is not editable.
Time zones on summer time should be indicated with an asterisk (*). According to the description of time zones on the User Information Channel, summer time is indicated with an asterisk (*), however, none of the time zones using summer time have asterisks.
The URLScraper channel does not pass the User-Agent information to the server from which it is making the request. In some cases, this header is needed to fulfill the request.
After the multi-profile fix, if the user changed the Layout Provider, many sync requests were generated. The amount of these requests causes a delayed response.
Internet Explorer caches content when the user sets the browser setting "Check for Newer Versions of stored pages" to "Never." This is because the Login Servlet does not set required Internet Explorer headers.
Cell padding around Tab Provider cannot be specified because of hard coded HTML in DesktopServlet.
Cell spacing cannot be specified in the main block of channels and providers.
Background color cannot be specified for main block of channels.
The iPlanet Portal Server 3.0 software does not provide the ability to maximize a provider. A provider can be minimized or restored, but cannot occupy the entire width of the Desktop without the presence of other providers.
A user who belongs to a non-default domain is taken back to the default domain's login page after a session timeout.
The Web server goes to sleep when the URLScraper is used to get SSL content.
The time zone setting in the User Information Provider cannot be updated.
High level caches are not updated when profile data changes, so changes in Desktop configuration are not synchronized across instances.
A multi-instance portal environment in which request handling is distributed by a load balancer that is not using sticky sessions causes changes in displayed channels to be undone by other instances.
Maximized channel with no content should display the message Content not available.
Edit Page of Netlet and Bookmark Provider can not be accessed after any one of the fields is deleted.
Entries with multiple sn and givenname do not display correctly in the User Info channel.
A URL scraped channel does not display JPEG files with a non-relative path.
The tab provider displays tabs in only right-to-left alignment. For more information, see "Tabbed Desktop" in this document.
The JSP provider cannot localize title or description. For information on the JSP Provider sample properties file, see "Localizing JSP Provider Titles and Descriptions" in this document.
Occasionally, the Desktop is displayed only after the entire timeout the default timeout is 30 seconds.
Detaching all channels on the Desktop causes an unrecoverable error that makes the Desktop unusable.
Desktop provider does not catch throwable, resulting in a Desktop error page with the message A fatal error has occurred displayed in the channel window.
Some attribute strings for Desktop tabs are displayed in English for other locales.
Desktop logs expired or invalid sessions as an errors instead of warnings in the debug log files. This can debug files to grow unnecessarily large.
URLScraperProvider does not preserve backward compatibility.
Channel titles are always displayed in the language stored in the profile service.
Changes to TimeZone are not effective until user logs in again.
Changing to layout Option Four causes wide channels to be removed.
Selecting Open all pages in the Desktop when editing bookmarks causes the javaScript function openURL to call the server twice in the URL.
The Channel Wizard works incorrectly when an in-line channel is created if the iSyndicate connector is installed.
Weather provider templates should not be installed. The product does not contain a weather provider.
Content provider should check for null provider in content provider edit page creation.
The URL scraper failed when it tried to fetch a URL that resulted in a redirect.
URL rewriting did not work for relative URLs in URL scraper.
Removing a channel with thin-thick-thin layout caused null pointer.
The iPlanet Portal Server gateway POST request forwarding performance inefficient.
In some cases, CLOSE_WAIT sockets accumulate and never get closed.
If an HTML form action is inside document.write function and is broken into two or more statements, gateway doesn't understand it as a single tag and therefore doesn't rewrite it.
gateway prints debug messages to console for short connections because exception messages are printed to standard out and standard err, rather than using the Debug class.
The Gateway redirect option does not base its decision on gateway profile. The gateway attempts to fetch the response for a URL request without first checking to see if the gateway scheme is "redirect."
When the iPlanet Portal Server http proxy is enabled, and the gateway is used under heavy load with HTML pages containing a large number of images, it starts giving StackOverFlow Error and stops responding.
Wildcard support for JavaScript variables does not exist. For URLs and variables which may be dynamically generated, it is not possible to define a rule that applies to them all without being able to specify a wildcard for the entry in the Gateway Profile.
The rewriter ignores content between nested SPAN tags. Service Pack 3 Hot Patch 1 broke the rewriting functionality of content between the SPAN tags in order for Microsoft Exchange to work through the gateway.
URLs are not rewritten inside JavaScript while adding a menu item. If javascript variables like top.location were added to the Rewrite javascript variables in urls section, they do not get rewritten correctly because of the presence of location in the Rewrite Javascript varibales function section.
If the domain, and path are not explicitly set, they are not prepended to the cookie name when the gateway wraps the header up and sends it to the client. In some cases this causes problems maintaining uniqueness.
The gateway blindly rewrites source tags even if they are empty. An empty source tag can cause an error 404 to occur. Once a 404 error has been reported in the frame, it is no longer accessible to JavaScript functions.
The gateway incorrectly handles multiple Content-Length headers. The first value us rewritten with the new length after translation and appended to the end of the request. However, the Internet Explorer browser uses the first content-length header it encounters which would be smaller than the translated length, which causes the page sent back to the client to be truncated.
Pages redirected through the gateway should have the option not to be cached. When surfing pages through the bookmark provider or by specifying the redirected URL in the location field of the browser, the content can be cached on a local system.
Relative URLs with no prepended path information embedded in remote JavaScript are not rewritten correctly on import.
The option to disable client-bound Netlet traffic from extending iPlanet Portal Server session is needed.
If an HTML page is written in different parts using the document.write function, the rewriter may not understand all the attributes and tags correctly because of the quotation marks.
Cookies are not set while using http-proxy, if the domain is not the iPlanet Portal Server's domain.
If an applet archive tag has multiple jar files separated by commas, only the first archive tag is rewritten.
The iPlanet Portal Server gateway has a problem re-writing URLs when it sees a codebase directive with an applet tag. The gateway does not translate any other <a href directive correctly within the HTML file even though the codebase should only be in scope until the closing APPLET tag.
The rewriter should not automatically rewrite SRC tags the iPlanet Portal Server gateway does not understand.
The iPlanet Portal Server gateway passes different Content-Length: size in the HTTP header than the actual size. This happens only when the iPlanet Portal Server gateway sends HTTP/1.0 302 Moved Temporarily. The difference is one byte (the actual payload is bigger).
In some cases the iPlanet Portal Server gateway hangs under load. The java process does not die, and new connections are accepted, but no response is returned.
The applet getCodeBase call fails through the iPlanet Portal Server gateway if BASE HREF is commented out.
The iplanet function causes an error when rewriting JavaScript variables.
The rewriter has no option for specifying a JavaScript function parameter that is either a URL or JavaScript.
The iPlanet Portal Server gateway incorrectly rewrites JavaScript programming language containing the style tag.
Rules containing dotted separators cannot be used in the specified iPlanet Portal Server gateway profile section "rewrite javascript variables function."
If the URL specifies the protocol in upper case, the rewriter will not rewrite the URL. For example, only URLs starting with http are rewritten, and URLs starting with Http: or HTTP are not rewritten.
Using Outlook Web Access and Internet Explorer in combination, causes errors when the inbox is opened through the iPlanet Portal Server gateway.
Sometimes under load, the content character set is forced to be converted into other character set than one specified in header of the HTML.
Relative URLs are not rewritten correctly if the absolute URL used for the BASE HREF value does not contain any path information.
A defect in the logging service causes the iPlanet Portal Server gateway to hangs on DNS lookup.
The iPlanet Portal Server gateway encounters an error when the location header is all lower case.
The last scraped page's iplanet function will take precedence, and all other URLs in other scraped pages will use its requestPHP variable value to be rewritten.
Pages are not displayed correctly through the gateway. BASE tags containing a target attribute are commented out.
Unencoded Korean characters in the request URL are not handled properly when the LANG setting for the iPlanet Portal Server gateway is "Ko."
Requests to single or double level domain are not adhering to the HTTP proxy rules.
URL rewriting fails for JavaScript strings that extend across several lines.
The iPlanet Portal Server gateway does not correctly rewrite the META tag when putting the URL in quotation marks.
The iPlanet Portal Server gateway does not store basic authentication credentials when using httpproxy.
Applet Parameters are not rewritten if the code contains a line break.
The URLrewriter cannot rewrite cookie paths that contain an underscore (_).
When the rewriter needs to add the iplanet function to "Rewrite JavaScript Variable Function" and there is no <head> tag, the iplanet function is placed in the middle of the HTML code.
The iplanet function has the variable requrl, which is not defined. If the iplanet function is called with an already rewritten URL, it produces JavaScript error.
The iPlanet Portal Server gateway moves a server into the unavailable list when it is unable to make a single socket connection to that server. The gateway does not retry to make the connection.
Cookies are not rewritten correctly for an iPlanet Portal Server gateway that is installed in a top level domain.
The iplanet function does not check to see if variables are null. This affects the rewriting of variables in imported JavaScript in the Exchange interface.
The gateway automatically forwards requests for nonexistent domains, creating a unnecessary traffic and putting undue load on the Gateway.
If the gateway socket timeout is not set for the erproxy, denial of service attacks can occur.
The gateway translates special characters when rewriting XML, causing incorrect XML syntax.
When a style attribute is followed by a boolean attribute and a DOMstring attribute, the rewriter throws a string out of bounds exception.
The gateway does not handle implied tags. The rewriter inserts <HEAD></HEAD> tag in the wrong place if a pair does do not already exist.
The rewriter does not ignore comments that occur prior to opening XSL tag, which breaks the message multi-view functionality in Microsoft Exchange.
The gateway does not distinguish between base href internal and external URLs.
Outlook Web Access 2000 does not work out-of-the-box. See "Using Outlook Web Access 2000" in this document.
The gateway cannot handle cookies differing only in path. For more information, see "Desktop and Provider Changes" in this document.
JavaScript window.location.path value is not rewritten correctly.
The gateway component does not rewrite JavaScript variables that contain escaped double quotes.
Internal applications cannot be accessed because cookie domain rewriting does not use gateway domain or cookie domains list.
Internal applications that use URLs in which the file path starts with the word login cannot be accessed when using personal digital certificates (PDCs). iPlanet Portal Server redirects these URLs to the Desktop.
The gateway does not rewrite cookies correctly when used with the HTTP Proxy.
Re-submitted HTTP posts to foreign hosts by the gateway contain no data.
The gateway component does not handle pages correctly when lines end with line feed only.
iPlanet Portal Server 3.0, Service Pack 3 does not work with iPlanet Messaging Server 5.1.
The gateway component should not add default port number to re-written links.
The gateway rewrites src= tags when it is an SSL site and the site is not in the rewrite domain/subdomain list.
The gateway does not display a URL correctly unless / follows the hostname.
If the socket connection cannot be created, the gateway sends a 502 HTTP error code to the client indicating that the server is unavailable. For information about the addition of the isp.gateway.sockretries parameter, see "Setting the Number of Socket Connection Retries" in this document.
HTTP basic auth caching (SSO) fails when using server HTTP proxy.
Referer headers must be forwarded so servers can track the user's URL.
The ipshttpd script does not set the maximum number of file descriptors to a high enough value for the HTTP proxy process, causing the ipshttpd process to run out of file descriptors. When that happens, ipshttpd stops responding.
Users cannot authenticate with Internet Explorer, if hostname contains capital letters.
If the server and the gateway are installed on two different machines, the iwtGateway.properties file is not installed in basedir/SUNWips/locale directory of the server machine. The gateway-related strings are displayed in the default language, English, for foreign languages on the server machine.
The URL rewriter incorrectly rewrites relative URLs by using the document's URL instead of its instead of its base URL (indicated by the BASE tag).
In some cases the gateway or HTTP proxy would not respond due to CLOSE_WAIT sockets accumulating, and not getting closed.
If an applet is between <OBJECT> and </OBJECT>, the URL rewriter does not rewrite the URL.
The URL rewriter does not rewrite the applet parameter value if there is space between an HTML tag's parameter name and value.
URL Scraper and RSS channel providers fail when load balancing is active.
URLscraper does not handle the character set from Content-Type.
Internet Explorer 5.5 cannot display Webmail application when used with the gateway.
The gateway component should use JSS for talking to the platform server in HTTPS mode.
Gateway boot process hangs if the server is not started first.
Rewriter did not work if a URL had no leading http:// and no port number specified.
Rewriter for applet tags could rewrite only limited number of URLs in a parameter.
Upgrade script does not give executable permissions to the web server stop script.
The ipsinstall script displays false error messages about missing patches.
When using iPlanet Portal Server with iPlanet Web Server 4.1 Service Pack 11, an improperly formed request using chunked transfer encoding is received by the web server it can cause a buffer overflow.
Install needs to check disk space for installing Java packages. If Java packages don't get installed, the install script fails.
Stop script stops all slapd processes and all external LDAP server processes.
The installation script requires a fully qualified domain name (FQDN) with three parts (separated by two dots). It does not accept an FQDN with only one dot.
Installing gateway with profile server, using non-default port for SSL, sets port to 443.
Service Pack 3 image should not include jdk1.2.2_05 patches.
Installing profile server with a web proxy causes ipsserver to fail.
The command line utility ipsadmin returns invalid XML if the attributes value contains special characters. If the administrator tries to use this XML file it gives SAXParserException.
Unable to change user attribute values to null using ipsadmin.
After installing iPlanet Portal Server Service Pack 4, unnecessary messages were displayed on console when using ipsadmin for any profile changes.
Importing privileges after accessing the Policy page requires relogging to view.
ipsadmin -import converts new attributes in previously existing components to lower case and reports all attributes of new components as already existing. This bug is fixed in the iPlanet Directory Server 4.12 release.
ipsserver stop script kills all HTTPD processes running on the server. In doing so, it may also kill some external iPlanet Web Servers running on the server. The ipsserver stop command should stop only relevant processes.
Incorrect country code for Japan in the iwtUser.properties file.
On Japanese localization, NetFile Java did not work on Solaris and Windows NT.
With the release of the iPlanet Portal Server Service Pack 3 software, log records written using the Logging API were logging userID as authentication. This makes logging useless because there is no way to associate any entry with any user.
When logging is disabled, the log client still sends the log message.
Oracle jdbc driver does not re-initialize when the database cycles off and on.
NetMail sessions are not released when the user logs only out of the iPlanet Portal Server Desktop.
Installing NetMail locally on a Macintosh client will break on Macintosh clients running Internet Explorer.
Double-byte nickname entries in NetMail Lite address book are not supported.
In the NetFile application, the Return key should choose OK to avoid having to move the hand from the keyboard to the mouse.
An incorrect error is reported when creating an existing directory.
Users are able to add nonexistent shares. If a non existing share is added and you try to open the share, an error occurs and permission denied. If the share is not present, the user should not be allowed to add it.
Multiple files are mailed as copies of the same message with one attachment at a time. They should be mailed as multiple attachments.
Japanese files and folder names are not displayed correctly on NetFile and NetFile Lite, which makes the navigation and transfer of these directories or files impossible.
When mailing a file in NetFile using the Mail button, the From: address values are sourced and filled in incorrectly.
NetFile Truncates directory listings for subfolders if the number of listings is more than approximately 30.
File listing does not work for Windows NT FTP server host types. The file listing is not viewable although the file can be uploaded correctly.
When deleting a file with NetFile FTP, a messaging saying that the file has been Deleted is displayed, but the file is not actually deleted. This problem occurs if the user deleting the file is different from the file owner.
When saving a file from the NetFile applet on the Macintosh using Internet Explorer 5 or MRJ, the name NetFileServlet is used as the filename in the dialog box. The actual filename gets ignored.
When more than one user is specified in the To field, using a comma as a separator, mail is sent to only one user.
Mail sent from NetFile containing Japanese characters gets corrupted.
When downloading any files with Internet Explorer using NetFile, the file extension becomes .NetFile.
When a large number of files is selected and the Mail button is clicked, the Mail dialog opens and is displayed huge horizontally.
Internationalization: A warning message is displayed when uploading multi-byte files in Netfile.
Mail form field values in NetFile are not checked uniformly.
File names are not displayed when mailing multiple files from the NetFile Java application. File names are now displayed as a comma separated list.
Sending a blank email reply with the NetFile application causes the browser to spin indefinitely.
The window for displaying files on right side is too small. The file name window has been changed to allow 11 additional characters.
NetFile FTP connection method does not work properly with server components using multiple network interfaces. The PORT command uses the wrong IP address when sending data back to the client.
The Print and Save functions don't work in Netscape Navigator for files sent by NetFile.
The NetFile Lite application incorrectly displays compressed file names when using Windows NT hosts.
NetFile Lite behavior, under certain circumstances, can compromise password security.
NetFile Lite can display only one share for Windows systems.
NetFile Lite does not save changes to host information upon exiting and saving the session.
NetFile has problems displaying hidden shares that have been defined by the administrator.
NetFile shares that have been defined through ipsadmin can be added again through the NetFile application resulting in duplicate shares.
Using the host info menu in NetFile to edit host information, such as user name and password, removes the shares associated with that host.
NetFile assumes that a system is valid without verifying that the system exists. If the system to which NetFile tries to connect does not exist, the NetFile application eventually times out.
NetFile applet occasionally does not pass the sessionid to the servlet during a servlet call, resulting in a session exception that causes the log files to get unnecessarily large.
If the server's LANG setting specifies Japanese or Chinese locale, NetFile download functions for image, HTML, and executable files do not work.
If the server's LANG setting specifies Japanese or Chinese locale, NetFile upload functions for image, HTML, and executable files do not work.
NetFile mail functionality can overwrite iPortal Web Server configuration files.
NetMail was unable to receive mail with attached text file sent from NetFile.
If a dynamic netlet rule with target listening on different ports is specified, it does not work properly and the target is set only for the first port.
Netlet does not work on a Macintosh machine because it cannot resolve localhost. It needs the value 127.0.0.1 instead.
The ability to increase the session time out when the user is working with the Netlet should be configurable.
The Netlet cannot find a PAC file when it is specified using a file URL. For example: file://.
Large PAC files are truncated when content length is not explicitly set.
With Internet Explorer, the Netlet does not connect to the server after the user logs out and then logs in again.
Current idle time is constantly reset by the Netlet when the MaxCache time value has been exceeded.
Netlet does not support Netscape with PAC files. For more information, see "Installed Software Modules, Customizations, and Third-Party Products" in Chapter 2 of the iPlanet Portal Server Installation Guide.
Dynamic rules should be supported when using FTP through a Netlet connection.
Netlet does not support .ins files for Internet Explorer Configuration. For more information, see "Configuring Internet Explorer INS Files" in this document.
Netlet activity is not monitored and causes a session idle time out even when the Netlet is in use.
The port number is not stripped from the host name when evaluating a PAC file.
The autoproxy does not work when the autoconfig URL does not point directly to a file or redirect to a file. For instance, if http://domain_name:1001 is used an exception is thrown.
PAC files that contain evaluation entries based on the client IP address either fail or are evaluated incorrectly.
Netlet applet is hardcoded for a maximum of ten connections per rule.
The global encryption version of Netlet Applet incorrectly shipped with the domestic version of iPlanet Portal Server 3.0, Service Pack 3.
The request XML document for any service gets corrupted under a heavy load. The PLLRequestServlet does not read the XML document correctly.
Sizes of PLL Session threadpool are not configurable, which causes the server to hang in some cases.
A certificate error occurs when using an HTTPS connection when the VIP name does not match the server name.
After installing the iPlanet Portal Server Service Pack 3 Hot Patch 1 software, a profileException is thrown saying that attribute iwtGateway-responsedelay is not found.
After multi-server fix, if a suborole has modified content, and the administrator has changed the upper domain or role, the change is visible only on the server on which the change was made. The change is not visible on the other platform servers.
If the iPlanet Portal Server software is configured to run SSL in open portal mode on port 80, users are not able to see the Desktop on Internet Explorer. Netscape works fine.
A single write operation produces a large number of LDAP reads.
The Profile service issues excessive requests for the domain list.
Unnecessary LDAP reads occur if a request has no iPlanet Portal Server cookie.
A single Desktop reload causes multiple sessionservice requests.
Every time a user logs in to the portal, the profile server receives an LDAP request.
Every time a user with a profile that is not already cached logs in, two LDAP requests are issued for their profile in immediate succession. Since user profiles are cached, only one request should be necessary.
Profile server should be able to reconnect to the LDAP server.
ipsadmin has wrong content type for UpdateProfileCache request.
Profile API returns valid profile object for non existing profiles.
Domain search did not search for users mapped from external LDAP. The search limit for external LDAP users is 400 users only.
External LDAP attribute mappings did not work with binary type attributes.
The steps to add a gateway are documented incorrectly in the iPlanet Portal Server 3.0 Administration Guide. For correct instructions, see "Adding a Gateway After Installation" in this document.
Document required disk space for /var; /etc; /opt; and installation directory.
Portal Server and gateway components on a single computer must use the same install directory.
Correct instructions for adding iwtTabProvider in selected channels.
This section provides information that supplements the iPlanet Portal Server Administration Guide. Topics include:
Documentation for iPlanet Portal Server is at this Web site:
http://docs.iplanet.com/docs/manuals/portal.html
Table 14 is a two column table that lists the gateway profile attributes. The first column contains the attribute name, and the second column provides a brief description of each attribute.
For more detailed information on configuring the gateway, see the iPlanet Portal Server Administrator's Guide 3.0 at:
For detailed information specifically related to rewriter configuration, see the SunONE Portal Server 3.0 Rewriter Configuration and Management Guide at:
http://www.sun.com/solutions/blueprints/
Attribute
Attribute Description
Allow connections to the gateway from browsers that only support weak (40 bit) encryption.
List of FORM tag attributes that get rewritten. The FORM tag attribute ACTION gets rewritten out of the box. Other attributes that might need to be added are INPUT and SELECT.
object_of_url_with_form form_name input_or_option_name [url_pattern]
If this attribute is set to true, the Gateway will rewrite any URL without checking the URLs subdomains and domains against entries in DNS Domains and Subdomains list.
List of gateways that require authentication by Personal Digital Certificate.
Web sites may be protected with HTTP Basic Authentication, requiring visitors to enter a username and password before viewing the site (the HTTP response code is 401 and WWW-authenticate: BASIC). Sun ONE Portal Server can save the username and password so that users need not re-enter their credentials when they revisit BASIC-protected web sites. These credentials are stored in the user profile on the Sun ONE Directory Server.
Sun ONE Portal Server utilizes a cookie to track user sessions. This cookie is forwarded to the server when the gateway makes HTTP requests to the server (for example, when the desktop servlet is called to generate the user's desktop page). Applications on the server use the cookie to validate and identify the user.
The Portal Server's cookie is not forwarded to HTTP requests made to machines other than the server, unless URLs on those machines are specified in the Forward Cookie URL Lists. Adding URLs to this list therefore enables servlets and CGIs to receive the Portal Server's cookie and use the APIs to identify the user.
Specifies whether cookies get rewritten and restored.
If false, cookies are forwarded, but not rewritten or restored
Specifies whether a Web Proxy is to be used. If a web proxy is specified in the DNS Domains and Subdomains list, the gateway checks this attribute.
This checkbox can be used in conjunction with:
If this box is checked, the Don't Use Web Proxy Enabled list can be used to add URLs that do not get proxied, but are contacted directly.
If the box is not checked, the Use Web Proxy Enabled list can be used to add URLs that do get proxied.
List of URLs that get proxied when the Use Intranet Web Proxy attribute is set to false.
List of URLs that do not get proxied when the Use Intranet Web Proxy attribute is set to true.
List of HTML attributes that contain URLs to be rewritten by the gateway. If an attribute in this list contains a URL, that URL will be rewritten.
These entries tell the gateway what web proxy (if any) to use when contacting specific subdomains in specific domains.
If Use Intranet Web Proxy is enabled, and the requested URL is not listed in the Do Not Use Webproxy URLs list, the gateway connects to the destination host through the specified proxy. The proxy, if specified, is looked up from the Proxies for Domains and Subdomains list.
If a web proxy is not indicated for the target URL through the DNS Domains and Subdomains list as described above, the gateway will connect to the destination host directly.
If a web proxy is indicated, the gateway will check the attribute Use Intranet Web Proxy.
Rewrites PCDATA. Add the tag name to the Rewrite Text data of XML document section. If the PCDATA is dependent on the tag attribute values, both the tag name and the attribute definition need to be added to the Rewrite Text Data of XML Document profile section.
Pre-populated with the entries required for Outlook Web Access 2000 to work through the gateway.
Used to rewrite XML values that contain URLs. Add a rule that contains the attribute name.
Pre-populated with the entries required for Outlook Web Access 2000 to work through the gateway.
Note: To differentiate specific tag names containing the same attribute names from having their values rewritten, specify a rule with the syntax attrName,tagName
Used for event handlers (HTML attributes that contain JavaScript whose values will attempt to be translated as URLs).
List of JavaScript function parameters to be rewritten. Used to rewrite document object methods. If the URL is a raw URL, then the function name can be added to the Rewrite JavaScript Function Parameters section of the gateway profile.
If the content is passed through the gateway that contains a call to a method, where the first parameter is not a raw URL, then the method would have to be moved from the default section of the gateway profile to the Rewrite JavaScript Function Parameters Function section.
List of JavaScript variables. The gateway rewrites the value of the URL that is assigned to the JavaScript variable. Used to rewrite document object properties.
Used to rewrite built-in JavaScript variables for which a relative URL is required, rather than translating its value into an absolute URL. location.pathname for instance should only specify the path portion of a URL.
Entries in this section of the gateway profile will likely be sparse, but this section can be useful if the content defines its own object rather than using the window object.
Used to rewrite JavaScript variables. If a JavaScript variable is used instead of a raw URL, the Rewrite JavaScript Variables Function inserts a function called iplanet within the SCRIPT tag and changes the variable name on the right side of the variable assignment to iplanet(variable_name).
Used to rewrite browser object methods that contain URLs. If the content is passed through the gateway that contains a call to a method, where the first parameter is not a raw URL, then the method would have to be moved from the default section of the gateway profile to the Rewrite JavaScript Function Parameters Function section.
An iplanet function is defined and the variable, or parameter in this case, is then wrapped within an iplanet function call.
The gateway will rewrite the HTML in the parameters of the JavaScript function if there is a match.
Used to rewrite URLs in nested JavaScript. Lets the rewriter know that the first parameter of the function call contains JavaScript content. So, the rule must be added to the Rewrite JavaScript Function Parameters in JavaScript section of the gateway profile.
Used in conjunction with the Rewrite JavaScript Function Parameters section. The rule must be also be added to the Rewrite JavaScript Function Parameters section.
Used to rewrite dynamically created HTML blocks. If an attribute is created dynamically by the client rather than passing through the gateway, which would normally translate the attribute value (the JavaScript variable that contains HTML to be rewritten requires a rule in the Rewrite JavaScript Variables in HTML section).
Used when rewriting JavaScript content for statements whose right side contains variable initializations that could have a right side that is a URL string literal. For the URL to be rewritten correctly, a rule address needs to be added to the Rewrite JavaScript Variables in URLs section of the gateway profile,
Used to rewrite Applet and Object attributes that contain URLs. The attributes ARCHIVE and CODEBASE are rewritten out-of-the-box.
object_of_applet/object_url applet_class/object_classid applet/object_parameter_name [url_pattern]
Specifies the time interval in milliseconds after which the gateway times out its connection with the browser.
This section is suitable for search, rewrite, and replace applications where JavaScript language dynamically creates HTML through multiple document.write function calls.
The rule is in the form of a URL pattern.
For more information see the section "Advanced Rewriter Concepts"
Specifies the MIME type. This section extends the rewriter functionality to other MIME types.
Specifies the maximum number of threads that can be pre-created in the gateway thread pool.
Rewrite JavaScript Function Parameters in JavaScript or a URL
Used when JavaScript functions do not differentiate the context of what can be passed to the function as a parameter. This section allows for some ambiguity in rewriting JavaScript function parameters. Specifically, when rewriting JavaScript function parameters that are themselves either JavaScript or a URL.
java_script_function_name: [y|], [y|], ...
For more information see the section, "Advanced Rewriter Concepts"
If this is disabled, only client activity on netlet connections extend the portal session (stop it from timing out). This is to avoid server side applications that send regular hello packets from keeping the session active when the user has abandoned it. However, some administrators may wish server side data to extend the session so that they can access system management or monitoring applications for which user interaction is relatively minor.
The port number on which all gateway instances registered against this profile server listen.
The protocol (HTTP or HTTPS) that all gateway instances registered against this profile server use.
Specifies that some URLs do not need any authentication. These are normally directories and folders that contain images.
List of hostnames with SSL certificates that are trusted, even if the certificate can not be verified.
If the http proxy is enabled, the gateway will send HTTP requests to the HTTP proxy instead of directly to the destination host. The HTTP proxy will then send the request to destination server.
The port number on which the HTTP Proxy (if enabled) listens
Enable proxying by the platform server of netlet traffic from the gateway to the target system. This avoids the need for internal systems accessed by the netlet to be directly reachable from the gateway.
The port number on which the Netlet Proxy (if enabled) listens.
Enable logging of connections made to the Gateway on the platform server via the logging service.
The iPlanet Portal Server Administration Guide 3.0 currently states the following:
The actual behavior of the non-portal server cookie management feature is to allow or prevent cookies from being rewritten and restored. Cookies set by the application server are not discarded when the option is set to false.
The non-portal cookie management feature handles cookies in the following manner:
This means that if the cookie is set from a different domain than that of the Gateway, and the non-portal server cookie management attribute is set to true, the Gateway will rewrite the cookie's domain and the browser will accept it. When the cookie is returned to the application, the Gateway will restore the cookie's original domain.
By setting this attribute to false, the Gateway does not rewrite the cookie. If the cookie is set from a different domain, the browser will not recognize it and will, therefore, reject the cookie. However, if the cookie is sent from the same domain as that of the Gateway, the browser will recognize the cookie as a valid cookie and will store it, even if the non-portal server cookie management attribute is set to false.
If this feature is enabled and later disabled, a cookie that has been previously set will not be restored to its correct domain when it is sent back to the application server.
Note
SSL certificate management changes have changed information for SSL certificates for the gateway component presented in Chapter 11 of the iPlanet Portal Server3.0 Administration Guide and Appendix A of the original iPlanet Portal Server 3.0 Installation Guide.
The following information replaces the existing documentation on SSL certificates for the gateway.
Documentation about certificates for the iPlanet Portal Server server component still applies.
Note
The certadmin script in installation_directory/SUNWips/bin/ wraps around the ipscertutil command for convenience and consistency with previous certificate administration. The certadmin script should satisfy the conventional needs of certificate administration. For additional functions, use the ipscertutil command directly. For example, use ipscertutil to delete a certificate from the certificate database. The command ipscertutil -H lists use.
Certificate-related files are located in /etc/opt/SUNWips/cert. Three of the five certificate files, cert7.db, key3.db, and secmod.db, are binary files containing data for certificates, keys, and cryptographic modules. These files can be manipulated implicitly by using the certadmin script.
These binary files have the same formats as the database files used by iPlanet Web Server. They are located in installation_directory/netscape/server4/alias. If necessary, they can be shared between the iPlanet Portal Server server and gateway components or the HTTP proxy.
The other two certificate files are hidden text files: .jsspass and .nickname. The .nickname file stores the names of the token and certificate that gateway currently uses, in the form of token_name:certificate_name. If using the default token (the token on the default internal software encryption module), omit the token name. In most cases, only the certificate name is stored in .nickname file.
The .jsspass file contains the password for the encryption module that iPlanet Portal Server gateway currently uses. The default module is the internal software module.
During the installation of the iPlanet Portal Server gateway component, a self-signed SSL certificate is created and installed. If necessary, use the certadmin script to do additional certificate administration.
Administrators use the certamin script to generate a self-signed certificate for the gateway. To do this, complete the following steps:
Multiple certificates can be stored in the database files. The one that the gateway component uses is identified by the .nickname file. You can edit this file to switch to a different existing certificate.
During installation of the gateway component of the Portal Server product, a self-signed certificate is created and installed. At any point after installation, you can install SSL certificates signed either by vendors who provide official certificate authority (CA) services or by your corporate CA.
Three main steps are involved in this task.
To generate a certificate signing request, complete the following steps:
The webmaster's email and phone number are required.
Note
A CSR is generated and stored in the file /tmp/csr.hostname and is printed to the screen so that you can copy and paste it.
To use the certificate signing request to order a certificate from a certificate authority, complete the following steps:
The following example omits the actual certificate data.
Include both the BEGIN CERTIFICATE line and the END CERTIFICATE line with the certificate in the file.
Note
To install the certificate from the CA in your local database files in /etc/opt/SUNWips/cert, complete the following steps:
The script asks you to enter certificate file name, certificate name and token name.
Once the certificate is installed in /etc/opt/SUNWips/cert, the screen prompt returns.
Tip
When the gateway is an SSL client, importing a root CA certification into the gateway's certificate database enables the gateway component to communicate with an Internet or an intranet HTTPS site. If the root certificate is not in the gateway's certificate database, the gateway component does not recognize the server's CA certificate, and the SSL handshake fails.
To import a root CA certificate into the gateway component's certificate database, complete the following steps:
If the gateway component is set up to communicate with an HTTPS site that presents a self-signed certificate, allowing the gateway component to trust any unknown CAs can be useful. However, this approach must be used with caution. See "Denying Unknown Certificate Authorities" for more information on configuring the gateway component.
Most well-known public certificate authorities are already included in the certificate database.
Tip
To view the list of Public CAs, compete the following steps:
Table 15 is a two column table that displays all public certificate authorities included in the certificate database by default. The first column contains the Certificate Authority name, and the second column lists heir trust attributes.
For information on modifying the trust attributes of a public CA, see "Modifying Trust Attributes of a Certificate."
The trust attributes of a certificate provide information about whether the certificate is a regular server certificate (also called user certificate) as opposed to a root certificate, and whether the certificate (in the case of a root certificate) can be trusted as the issuer of a server or client certificate.
Three trust categories are available for each certificate: SSL, email, and object signing. In the context of the gateway component, only the first category is useful. In each category position, zero or more attribute codes are used.
Table 16 is a two column table that lists the certificate trust attributes. The first column lists the possible attribute values, and the second column provides a description of that attribute.
Attribute codes for the categories are separated by commas, and the entire set of attributes is enclosed by quotation marks. For example, the self-signed certificate generated and installed during the gateway installation is marked u,u,u to designate that it is a server certificate (user certificate), as opposed to a root CA certificate.
You can use the certificate administration script to view all certificates and their corresponding trust attributes.
To view the trust attributes of a certificate, complete the following steps:
The trust attributes of a certificate must be modified if client authentication is used with the gateway.
An example of client authentication is PDC (Personal Digital Certificate) as described in Chapter 6 of the iPlanet Portal Server 3.0 Administration Guide. The CA that issues the PDCs must be trusted by the gateway. For example, the CA certificate should thus be marked T for SSL.
To set the trust attribute for a certificate, complete the following steps:
Once the certificate trust attribute is changed, the gateway recognizes client certificates signed by that certificate authority.
The first two steps in the procedure "To Add a Gateway After Installation" in the iPlanet Portal Server Administration Guide are incorrect. The correct procedure for adding a gateway after installation is described here.
To add a gateway after you install Portal Server, complete the following steps:
The new gateway uses the default platform values for gateway port number, name of platform profile, retry interval, and default domain.
For example, if the new gateway host name is host1.domain1.com and the iPlanet Portal Server host name is host2.domain2.com, then domain1.com is added to the Cookie Domain List attribute.
If you have problems with iPlanet Portal Server, contact iPlanet customer support using one of the following mechanisms:
So that we can best assist you in resolving problems, please have the following information available when contacting customer support:
Use of iPlanet Portal Server is subject to the terms described in the license agreement accompanying it.
Copyright © 2003 Sun Microsystems, Inc. All rights reserved.
Sun, Sun Microsystems, the Sun logo, iPlanet, the iPlanet logo, Java, Java Development Kit, JKD, JavaServer Pages, JSP, Java Virtual Machine, JVM, Javadoc, JavaScript, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Netscape, the Netscape logo, and Netscape Navigator is a trademark or registered trademark of Netscape Communications Corporation in the United States and other countries.UNIX is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd.
All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
Federal Acquisitions: Commercial Software -- Government Users Subject to Standard License Terms and Conditions The product described in this document is distributed under licenses restricting its use, copying, distribution, and decompilation. No part of the product or this document may be reproduced in any form by any means without prior written authorization of Sun Microsystems, Inc. and its licensers, if any.
THIS DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
Copyright © 2003 Sun Microsystems, Inc. Tous droits réservés.
Sun, Sun Microsystems, le logo Sun, iPlanet, et le logo iPlanet, Java, Java Development Kit, JKD, JavaServer Pages, JSP, Java Virtual Machine, JVM, Javadoc, JavaScript, et Solaris sont des marques de fabrique ou des marques déposées de Sun Microsystems, Inc. aux Etats-Unis et d'autre pays. Netscape, le logo Netscape N, et Netscape Navigator sont marques de Netscape Communications Corporation aux Etats-Unis et dans d'autres pays. UNIX est une marque enregistree aux Etats-Unis et dans d'autres pays et licenciée exclusivement par X/Open Company Ltd.
Toutes les marques SPARC, utilisées sous licence, sont des marques déposées ou enregistrées de SPARC International, Inc. aux Etats-Unis et dans d'autres pays. Les produits portant les marques SPARC sont basés sur une architecture développée par Sun Microsystems, Inc.
Le produit dé crit dans ce document est distribué selon desconditions de licence qui en restreignent l'utilisation, la copie, la distribution et la décompilation. Aucune partie de ce produit ni de ce document ne peut être reproduite sous quelque forme ou par quelque moyen que ce soit sans l'autorisation écrite préalable de Sun Microsystems, Inc., le cas échéant, de ses bailleurs de licence.
CETTE DOCUMENTATION EST FOURNIE "EN L'ÉTAT", ET TOUTES CONDITIONS EXPRESSES OU IMPLICITES, TOUTES REPRÉSENTATIONS ET TOUTES GARANTIES, Y COMPRIS TOUTE GARANTIE IMPLICITE D'APTITUDE À LA VENTE, OU À UN BUT PARTICULIER OU DE NON CONTREFAÇON SONT EXCLUES, EXCEPTÉ DANS LA MESURE OÙ DE TELLES EXCLUSIONS SERAIENT CONTRAIRES À LA LOI.
Last Updated July 29, 2003