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.

. 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. For example.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.

. but you must then drill down. including HTTP redirect. and also assign one to the "Search Center" results page (tab) . I named the friendly name of Search center page /search/center. HTTP anchors. we want to assign a friendly name to the Search Center link from the banner. Under the "Search Center" banner entry. it uses that friendly name in all aspects of the request/response flow. On my system. When configuring the friendly names to the Search Center results page. you must apply PK71176 to restore this function. Using the . In our case. the page showing the real search results is actually the 2nd page under the main page in the hierarchy . For WebSphere Portal v6. Modify the existing PZN visibility rules: In previous version of WebSphere Portal.you must assign friendly names not only to the “Search Center” banner link under Content_Root. ensure you watch WHICH search page you assign the friendly name to. as well as a friendly name to the Search Center tab containing the results. you must assign a friendly name to a page at each level of navigation. enter http://hostname/wps/myportal/search/center and verify the URL Location or Address bar contains /search/center after the /wps/myportal. In order to get multiple levels of navigation included. 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. and HTTP Referer header values..1. To test.When the portal engine determines a page has a friendly name assigned to it.

Select the “Browser Capability -> Referer” conditional and add it as an OR operator.LiveHttpHeaders browser plug-in. . Once you've applied PK71176. and edit your rule. 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. you should be able to add a new conditional to your rule.

PznTransformationModel. when I first navigate to the page to be normally hidden. the rule is THEN fired. the cached value is used and the page is still hidden. and cached.properties Use this property to determine whether or not to cache the results of rules 1.websphere.invalidate(request.Year is 1997 or current Browser Capability. so my ruleName is “/mySearchRule”.attributeBasedAdmin. the page will be displayed. when I search for this page. Enter your full friendly name as the value. we would like the rule to be invoked every time. rulename) Where: -request is the PortletRequest and -ruleName is a String relative to the PZN Workspace. if I choose to NOT navigate to the page to be hidden's parent. your existing visibility rule logic is applied. after the PZN engine executes a rule once. My rule is a sibling to the alwaysHide rule immediately under /Workspace. My resulting rule is shown below: Show page or portlet when current Date.Referer includes /search/center Otherwise hide Following this rule. When the search results present the link to the hidden page. the cached value of SHOW still applies and I can still see the page. For example. the PZN rules engine caches many aspects of the attribute based administration rules. used in attribute based admin. and evaluated to SHOW.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.enableCaching=false 2.personalization. and click on the search results link in the Search Center.transformation. One item of specific interest which is related to our steps here is the cache of the rule results. If it was determined to be a link from the Search Center page. If the page is not to be shown. In our case. it caches the value of whether to HIDE or SHOW a page. the rule is cached in the Portal JVM to indicate to HIDE this page – it didn't have a referer of /search/center. One alternative is to completely disable the rule result caching: 1) Edit the following file to disable caching: /PortalServer/config/config/services/PersonalizationService. As a result of our changes so far. rulesEngine. Restart Portal A second alternative involves programmatically/manually invalidating individual rule result cache using the Personalization public API method call: com. and I click on it. because the value of the referer header changes from request to request. when returning to the hidden page without going through the Search center. Modify the default rule caching policy: By default. and immediately execute a search. However. the rule has not yet been invoked for my user session. the rule would then interrogate the Referer HTTP header.ibm. . there are inconsistent behaviors seen due to the caching. Conversely. This is pretty close to working how I want it to. but after a few more clicks to other pages. Per user.

Sign up to vote on this title
UsefulNot useful