Web Content Viewer best practices

Web Content Viewer best practices

+
Search Tips | Advanced Search

User authentication

User authentication to Web Content Viewers is managed by WebSphere Portal and IBM WAS.
When displaying content from multiple servers using Web Content Viewers you should enable single sign-on between the servers. See Implementing single sign-on to minimize Web user authentications in the WAS information center for details.

User access to Web Content Management content and components

Users will only be able to view content and components that either their Portal user's logon or a credential vault slot has access to.
If a Portal user's logon or a credential vault slot does not have sufficient rights in Web Content Management to view a Web Content Management content or component, errors may occur.

Content and component design
Not all content or components built in a Web Content Management solution are suitable for inclusion within an WebSphere Portal page:

Web Content Management content or components to be displayed within a WebSphere Portal page should be self-contained and not rely on other Web Content Management content or components.
When creating presentation templates or page styles to use when displaying Web Content Management content within a portlet, it is best practice to reference just the content you would like to display. Components, such as menus and navigators, should be displayed in separate portlets and linked to the Content Portlet as required.
JavaScript URLs will not work.

Using JavaScript
When a Web page is rendered via the Web Content Management application, some tags may be rewritten. The Web Content Management application uses double quotes for attributes in HTML tags. If you use JavaScript to produce HTML tags, the Web Content Management application will not recognize them if you use single quotes.

Path component tags

The URLs generated by the path component will be fully qualified when viewed through a portal.
To generate URLs with no prefix, use the following "Type" parameters instead of the standard parameters:

Type="noprefixbase" instead of Type="base"
Type="noprefixservlet" instead of Type="servlet"
Type="Prefix". When viewed through portal the, prefix value will be printed. If no prefix exists then empty string is returned.

Using the EditLive editor in local Web Content Viewer portlets

To use the EditLive editor in a Local Web Content Viewer portlet add a new configuration parameter to the portlet configuration:

Go to Administration > Portlet Management > Portlets.
Open the Web content Viewer portlet in configuration mode.
Type WCM_RICH_TEXT_EDITOR in the New Parameter field.
Type /wps/ephox;/jsp/html/EditLiveJavaEditor.jsp in the New Value field.
Click Add.
Click OK.

This setting will be the default configuration for all authoring portlets that have not had their shared settings edited.
To restore a portlet to its Configure mode, delete the portlet from the page and add it back.
To use the EditLive editor in a JSR 286 Web Content Viewer portlet either:

edit the configuration setting of the Web Content Authoring portlet:

Go to Applications > Content > Web Content Management.
Click Configure to open the Web Content Authoring portlet in configuration mode.
Select Extended Editor under the Rich Text options.
Click OK.
Click Done.

edit the shared settings of the authoring portlet on the hidden Web Content Management page:

Go to Administration > Portal User Interface > Manage Pages.
Search for the page named Web Content Management and open its layout view.
Edit the shared settings of the Web Content Authoring portlet.
Select Extended Editor under the Rich Text options.
Click OK.
Click Done.

Authoring template editor settings
The default editor set in an authoring template will override the rich text editor settings for any portlet.

Using remote Web Content Viewers with credential vault authentication
When using remote Web Content Viewers that are configured to use content from remote WebSphere Portal servers, either:

Disable LTPA. This is because with LTPA enabled without single sign-on, you will be logged out each time you access a different server.
If single sign-on is enabled with LTPA, the user will be granted the same access rights of the credential vault user.
Use a different domain name for the server hosting the remote Web Content Viewer.
Enter an IP address instead of a domain name when configuring the remote Web Content Viewer.

Configure the remote Web Content Viewer to connect to a clustered Web Content Management URL

You may receive errors when using the remote Web Content Viewer to connect to a clustered Web Content Management URL. This occurs when the WebSphere Portal Server and the Web Content Management server are accessed by the same host. This is because they are both trying to use the same cookie. By default, an Application Server uses a cookie with the name of JSESSIONID as the key to maintain session for that host. Since the Web Content Management server is accessed by the same host, the Portal Server cookie overwrites the Web Content Management cookie that maintains the session and vice versa. Logout is the result of losing a session.

Table 1. Possible Solutions

Solution Details
Use local Web Content Viewers Local Web Content Viewers can be used to access the same content on different servers in a clustered environment.
Use the IP address You can use the IP address of the Web Content Management server instead of the HOST name when configuring the portlet.
Assign two host names You can assign two host names to the server running both WebSphere Portal Server and Web Content Management and use one host name for Web Content Management and the other when configuring the portlet. There are two ways of doing this:

Assign two IP addresses to the Web Content Management server and assign a different host name to each IP.
Assign two Host names to the same IP in a DNS.

Change the default cookie name You could also change the default cookie name used by one of the servers:

Log in to the administrative console and go to Servers > Server Types > WebSphere appservers > portal_server.
Select Web Container Settings -> Session management.
Click on the "Enable Cookies" link. (Leave it checked.)
Change the cookie name from JSESSIONID to JSESSIONID2.
Click Apply and then Save the changes
Restart WebSphere Portal.

Using the Web 2.0 theme with a remote Web Content Viewer

To use the Web 2.0 theme with a remote Web Content Viewer create a HTTP proxy for AJAX. This is because when the Web 2.0 theme is used, content is being delivered from different domains. By default, the AJAX proxy is set to not allow any cross domain requests for security reasons. You will need to create a HTTP proxy for AJAX to allow the remote Web Content Viewer to render content in the Web 2.0 theme. See HTTP proxy for AJAX applications for further information.

Export remote Web Content Viewers

If the create-oids option is set to "true" when exporting portal pages containing remote Web Content Viewers, edit the configuration of the remote Web Content Viewer on the server the portal page has been exported to and re-select the page to broadcast to if using the "another page" broadcast link option.

Other limitations

The results of a POST in a form are only displayed within the portlet that sent the POST. You cannot send the result of a POST to another portlet.
The Web Content Management application can not be accessed behind a firewall. This is because Web Content Management will still need to be accessed directly for images and other resources.
An anonymous WebSphere Portal Server user will also be classed as an anonymous Web Content Management user so that the logon override does not work for anonymous users.
If a Web Content Management proxy server is being used with Web Content Viewers, all URLs rewritten by the proxy will not be fully-qualified, but server-relative instead.
To address this issue, redirect mappings can be created in the HTTP Server configuration that will pass the URLs to the proxy server.
Category selection trees cannot be used with the local Web Content Viewer.
Only advanced caching can be used with a local Web Content Viewer.
If you use a local Web Content Viewer with CSA (Client-Side Aggregation) you may recieve a "wcmHideCurrentContextMenu is not defined" error when switching from the inline authoring user interface back to the normal view. If this error occurs, refresh the page the page should render correctly.

Parent topic:
Display content with Web Content Viewers

Solution	Details
Use local Web Content Viewers	Local Web Content Viewers can be used to access the same content on different servers in a clustered environment.
Use the IP address	You can use the IP address of the Web Content Management server instead of the HOST name when configuring the portlet.
Assign two host names	You can assign two host names to the server running both WebSphere Portal Server and Web Content Management and use one host name for Web Content Management and the other when configuring the portlet. There are two ways of doing this: Assign two IP addresses to the Web Content Management server and assign a different host name to each IP. Assign two Host names to the same IP in a DNS.
Change the default cookie name	You could also change the default cookie name used by one of the servers: Log in to the administrative console and go to Servers > Server Types > WebSphere appservers > portal_server. Select Web Container Settings -> Session management. Click on the "Enable Cookies" link. (Leave it checked.) Change the cookie name from JSESSIONID to JSESSIONID2. Click Apply and then Save the changes Restart WebSphere Portal.