Page visibility rules and unreachable Search results
Paul Kelsey, firstname.lastname@example.org
There are 2 primary ways to control a users' view into their Portal Server:
Portal Access Control (PAC), and Attribute based administration. PAC
is administered using the Resource Permissions portlet, which allows you
to set definitive user and group membership into predefined roles that
apply to every portal resource (page, portlet, etc). If you are not a member
of the appropriate role on a given portal resource, you will not be able
to access that resource through any means. PAC is
and is hardened. Almost all of the portal experience is scoped to
what the user is allowed to do in PAC.
In contrast, Attribute based administration relies on Personalization (PZN)
visibility rules offers and greater flexibility in the conditions in which
administrators can affect whether a user or set of users can act on a page.
For example, administrators may want a portal page to be visible to users
during the hours of 9AM until 5PM. A single, simple PZN visibility rule
can be associated with that page to accomplish this behavior and
that behavior applied to all portal users.
It is important to note that Attribute based administration using PZN visibility
rules is not the same as PAC, and does NOT enforce portal security
!! Because of this, a problem with using PZN visibility rules
to control navigation hierarchy is related to the Portal search function.
Search results are not limited to the pages that you can see
the portal navigation, they are scoped to pages you are allowed
For example, lets assume when user “Joe” logs into his portal,
he does not see the page named “Manage workers” because of a
conditional execution of a PZN visibility rule set on that page. Lets
also assume that Joe is granted membership to the User
role on that
page, so he is allowed to see the page according to PAC. If Joe uses the
portal search center and searches on the String “Manage”, the Manage
workers page will
show up in the search results. When
Joe clicks the page in the search results portlet, the page attempts to
be rendered; however, the visibility rule does not allow the page to be
rendered. Instead, Joe is taken to the first viewable page in the navigation
hierarchy of the parent page of the results page.
In this scenario, the search results revealed to Joe a page that matched
his search is mistakenly available for him to view.
This solution makes the assumption that you would like a page or set of
pages to be displayed if they match a users' search query. If you want
to consistently deny the user access to the pages, you should modify the
PAC permissions using the Resource Permissions portlet.
The proposed solution is to use a combination of friendly URLs assignments
and visibility rule conditions to normally hide a page from a user's navigation,
but if the page is returned as a search result, the page may be displayed.
Assign Friendly name to Search Results page:
A friendly name on a portal page is assigned using the Page properties
portlet and provides page owners the ability to have their page addressable
via the URL location or Address bar. For example, the following friendly
name assignment would allow an authenticated portal user to type http://hostname/wps/myportal/search
and be taken directly to the Welcome tab under the Search Center.
When the portal engine determines a page has a friendly name assigned to
it, it uses that friendly name in all aspects of the request/response flow,
including HTTP redirect, HTTP anchors, and HTTP Referer header values.
In order to get multiple levels of navigation included, you must assign
a friendly name to a page at each level of navigation
. In our case,
we want to assign a friendly name to the Search Center link from the banner,
as well as a friendly name to the Search Center tab containing the results.
When configuring the friendly names to the Search Center results page,
ensure you watch WHICH search page you assign the friendly name to. Under
the "Search Center" banner entry, the page showing
the real search results is actually the 2nd page under the main page in
the hierarchy - you must assign friendly names not only to the “Search
Center” banner link under Content_Root, but you must then drill down,
and also assign one to the "Search Center" results page (tab)
To test, enter http://hostname/wps/myportal/search/center
and verify the URL Location or Address
bar contains /search/center
after the /wps/myportal.
Modify the existing PZN visibility rules:
In previous version of WebSphere Portal, the PZN rule editor and engine
allowed the value of the Browser “Referer:” HTTP header to be an operand
in determining the visibility of a page. For WebSphere Portal v6.1,
you must apply PK71176 to restore this function.
On my system, I named the friendly name of Search center page /search/center.
Using the LiveHttpHeaders browser
plug-in, I can watch the headers sent to portal when clicking a link on
the Search Center results page containing the Referer: HTTP header. Note
the existence of the /search/center
in the Referer header:
Navigate to the Applications -> Content -> Personalization ->
Business Rules page, and edit your rule. Once you've applied PK71176, you
should be able to add a new conditional to your rule. Select the
“Browser Capability -> Referer” conditional and add it as an
Make sure to change the operation on the condition from is
– because an exact match on the Referer field is not possible for
all users. Enter your full friendly name as the value. My resulting rule
is shown below:
Show page or portlet when
current Date.Year is 1997 or
current Browser Capability.Referer includes /search/center
Following this rule, your existing visibility rule logic is applied;
If the page is not
to be shown, the rule would then interrogate
the Referer HTTP header. If it was determined to be a link from the Search
Center page, the page will be displayed.
Modify the default rule caching policy:
By default, the PZN rules engine caches many aspects of the attribute based
administration rules. One item of specific interest which is related to
our steps here is the cache of the rule results. Per user,
after the PZN engine executes a rule once, it caches the value of whether
to HIDE or SHOW a page.
In our case, we would like the rule to be invoked every time, because
the value of the referer header changes from request to request.
As a result of our changes so far, there are inconsistent behaviors seen
due to the caching. For example, when I first navigate to the page to be
normally hidden, the rule is cached in the Portal JVM to indicate to HIDE
this page – it didn't have a referer of /search/center.
However, when I search for
this page, and click on the search results link in the Search Center, the
cached value is used and the page is still hidden.
Conversely, if I choose to NOT navigate to the page to be hidden's parent,
and immediately execute a search, the rule has not yet been invoked for
my user session. When the search results present the link to the hidden
page, and I click on it, the rule is THEN fired, and evaluated to SHOW,
and cached. This is pretty close to working how I want it to, but
after a few more clicks to other pages, when returning to the hidden page
without going through the Search center, the cached value of SHOW still
applies and I can still see the page.
One alternative is to completely disable the rule result caching:
1) Edit the following file to disable caching:
- Use this property to determine whether or not to cache the results of
- used in attribute based admin.
2) Restart Portal
A second alternative involves programmatically/manually invalidating individual
rule result cache using the Personalization public API method call:
-request is the PortletRequest and
-ruleName is a String relative to the PZN Workspace. My rule is a sibling
to the alwaysHide
rule immediately under /Workspace, so my ruleName is “/mySearchRule”.
Running this PZN API call on WebSphere Portal v6.1 causes the following
[9/30/08 16:37:56:183 EDT] 00000063 SystemErr R java.lang.NullPointerException
However, existing Portal APAR PK59544 corrects this issue.
After performing these steps, you can alleviate the confusion of pages
hidden by visibility rules showing up in search results.