WebSphere Portal: users versus spiders - form reset issue

Some users can run afoul of Portal's user-agent rules. Symptoms include the inability to log in and form submissions just causing page refreshes where all the form data is lost.

The problem is an intersection of two things:

• Pestware installed in the browser that changes the user-agent.
• WebSphere Portal misinterpreting the user-agent type and altering application behaviour.

See Technote 1441915 for IBM's support analysis.

Reproducing the problem

The problem can be reproduced by modifying the identifying information the browser sends with every HTTP request. The User Agent Switcher add-on in Firefox or a similar tool can be used to do this. Just add the word Search to the user-agent string.

The cause

Portal can utilize user-agent matching rules to serve different content to different devices. This was more useful when some mobile devices used their own markup. In this instance, Portal turns action URLs typically used in forms into render URLs, probably to prevent inadvertant invocation of processAction implementations by bots.

Fixing the issue

The rules can be amended via the web interface, but Portal's XmlAccess tool can be used to automate configuration change across environments.

Backup

The following script can export the search engine rule:

<?xml version="1.0" encoding="UTF-8"?>
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"
    type="export">
  <portal action="locate">
    <client action="export" uniquename="wps.client.search" />
  </portal>
</request>

The exported configuration can be run as a script to restore the rule:

<?xml version="1.0" encoding="UTF-8"?>
<!-- IBM WebSphere Portal/7.0 build wpnext_528_01 exported on Wed Jun 27 21:55:49 BST 2012 from localhost.localdomain/127.0.0.1 -->
<!-- 1 [client ZM_CGAH47L00GVLB0IAH1QQUL00C5 uniquename=wps.client.search name=Search] -->
<request build="wpnext_528_01" type="update" version="7.0.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd">
    <portal action="locate">
        <client action="update" domain="rel" manufacturer="Search" markup="html" markup-version="Search" name="Search" objectid="ZM_CGAH47L00GVLB0IAH1QQUL00C5" ordinal="410" uniquename="wps.client.search">
            <useragent-pattern>(.*(B|b)ot.*)|(.*BOT.*)|(.*(S|s)pider.*)|(.*(S|s)earch.*)|(.*(C|c)rawl(er)?.*)|(.*(G|g)rabber.*)|(.*(Y|y)ahoo.*)|(.*(S|s)lurp.*)|(.*Lycos.*)|(.*Wget.*)</useragent-pattern>
            <client-capability update="set">HTML_3_0</client-capability>
            <client-capability update="set">HTML_4_0</client-capability>
            <client-capability update="set">HTML_3_2</client-capability>
            <client-capability update="set">HTML_IFRAME</client-capability>
            <client-capability update="set">HTML_FRAME</client-capability>
            <client-capability update="set">HTML_TABLE</client-capability>
            <client-capability update="set">HTML_NESTED_TABLE</client-capability>
            <client-capability update="set">HTML_SEARCH</client-capability>
            <client-capability update="set">HTML_2_0</client-capability>
            <client-capability update="set">HTML_CSS</client-capability>
        </client>
    </portal>
    <status element="all" result="ok"/>
</request>

Deleting the rule

This script will remove the rule:

<?xml version="1.0" encoding="UTF-8"?>
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"
    type="update">
  <portal action="locate">
    <client action="delete" uniquename="wps.client.search" />
  </portal>
</request>

Scripts were written for and tested against WebSphere Portal 7.