Page visibility rules and unreachable Search results

Introduction 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 portal security, 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 in the portal navigation, they are scoped to pages you are allowed to see in PAC. 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. Proposed Solution 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 OR operator.

Make sure to change the operation on the condition from is to includes 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 Otherwise hide 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: /PortalServer/config/config/services/PersonalizationService.properties Use this property to determine whether or not to cache the results of rules 1. used in attribute based admin. rulesEngine.attributeBasedAdmin.enableCaching=false 2. Restart Portal A second alternative involves programmatically/manually invalidating individual rule result cache using the Personalization public API method call: com.ibm.websphere.personalization.transformation.PznTransformationModel.invalidate(request, rulename) Where: -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.