This action might not be possible to undo. Are you sure you want to continue?
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.
enter http://hostname/wps/myportal/search/center and verify the URL Location or Address bar contains /search/center after the /wps/myportal. HTTP anchors. I named the friendly name of Search center page /search/center.. On my system. it uses that friendly name in all aspects of the request/response flow.When the portal engine determines a page has a friendly name assigned to it. 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 . Modify the existing PZN visibility rules: In previous version of WebSphere Portal. we want to assign a friendly name to the Search Center link from the banner. When configuring the friendly names to the Search Center results page. and also assign one to the "Search Center" results page (tab) . For WebSphere Portal v6. Using the . 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. but you must then drill down. To test.. and HTTP Referer header values. ensure you watch WHICH search page you assign the friendly name to. In our case. In order to get multiple levels of navigation included. you must assign a friendly name to a page at each level of navigation.you must assign friendly names not only to the “Search Center” banner link under Content_Root. including HTTP redirect. as well as a friendly name to the Search Center tab containing the results.1. you must apply PK71176 to restore this function.
Select the “Browser Capability -> Referer” conditional and add it as an OR operator. and edit your rule. .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. you should be able to add a new conditional to your rule. Note the existence of the /search/center in the Referer header: Navigate to the Applications -> Content -> Personalization -> Business Rules page. Once you've applied PK71176.
Per user. because the value of the referer header changes from request to request. One item of specific interest which is related to our steps here is the cache of the rule results. the PZN rules engine caches many aspects of the attribute based administration rules.websphere. This is pretty close to working how I want it to.PznTransformationModel. If the page is not to be shown. rulesEngine. Modify the default rule caching policy: By default. the cached value is used and the page is still hidden. If it was determined to be a link from the Search Center page. there are inconsistent behaviors seen due to the caching. Conversely. if I choose to NOT navigate to the page to be hidden's parent. the rule would then interrogate the Referer HTTP header.properties Use this property to determine whether or not to cache the results of rules 1.attributeBasedAdmin. the rule is cached in the Portal JVM to indicate to HIDE this page – it didn't have a referer of /search/center.Year is 1997 or current Browser Capability. As a result of our changes so far.personalization. .invalidate(request. it caches the value of whether to HIDE or SHOW a page. and immediately execute a search. When the search results present the link to the hidden page. My resulting rule is shown below: Show page or portlet when current Date. and evaluated to SHOW. and click on the search results link in the Search Center. Restart Portal A second alternative involves programmatically/manually invalidating individual rule result cache using the Personalization public API method call: com. Enter your full friendly name as the value. One alternative is to completely disable the rule result caching: 1) Edit the following file to disable caching: /PortalServer/config/config/services/PersonalizationService. For example. but after a few more clicks to other pages. My rule is a sibling to the alwaysHide rule immediately under /Workspace. the page will be displayed.enableCaching=false 2. rulename) Where: -request is the PortletRequest and -ruleName is a String relative to the PZN Workspace. after the PZN engine executes a rule once. However.Referer includes /search/center Otherwise hide Following this rule. the rule has not yet been invoked for my user session. when I first navigate to the page to be normally hidden. In our case.transformation. your existing visibility rule logic is applied. and I click on it. the cached value of SHOW still applies and I can still see the page. so my ruleName is “/mySearchRule”. the rule is THEN fired. we would like the rule to be invoked every time. when I search for this page. used in attribute based admin.ibm.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. when returning to the hidden page without going through the Search center. and cached.
This action might not be possible to undo. Are you sure you want to continue?