The Q&D approach is to simply hack the relevant theme JSPs, but we don't want to do that - we want a far more elegant solution that can be implemented by a non-developer ( like me ).
Using this Technote as source: -
I established that it is possible to enable AND disable these two links via a pair of XML files and a script.
In essence, you use an XML script via the built-in XMLAccess tool to export the relevant elements of the theme policy - this generates an XML file which can then be edited to enable or disable the links.
First, you need to export the theme policy by creating an XML file, ExportPages.xml, containing the following text: -
<?xml version="1.0" encoding="UTF-8"?>
<request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"
type="export">
<portal action="locate">
<content-node action="export" uniquename="wps.Login"/>
<content-node action="export" uniquename="wps.Selfcare"/>
</portal>
</request>
I used VI to create the file - other editors are available - and I placed the file in /tmp on my Linux-based portal server.
I then ran the following commands to export the relevant elements of the theme policy to another XML file - /tmp/Login_Selfcare.xml : -
cd /opt/IBM/WebSphere/AppServer/profiles/wp_profile/PortalServer/bin
./xmlaccess.sh -in /tmp/ExportPages.xml -out /tmp/Login_Selfcare.xml -url http://portaldemo.uk.ibm.com:10040/wps/config -user wpsadmin -password passw0rd
( note that the URL is /wps/config rather than the more usual /wps/portal )
I then BACKED UP and edited the generated file, /tmp/Login_Selfcare.xml looking for: -
<content-node action="update" active="true" allportletsallowed="true" content-parentref="6_000000000000000000000000A0" create-type="explicit" domain="rel" objectid="6_CGAH47L0082M302B566VO730M6" ordinal="350" type="page" uniquename="wps.Login">
and: -
<content-node action="update" active="true" allportletsallowed="true" content-parentref="6_000000000000000000000000A0" create-type="explicit" domain="rel" objectid="6_CGAH47L0082M302B566VO730E2" ordinal="1400" type="page" uniquename="wps.Selfcare">
( note that the specifics will vary from installation to installation - if needed, merely search for the string "<content-node action="update" active="true""
The flag active="true" means that both links will be displayed in the theme, therefore I simply changed this flag to read active="false" : -
<content-node action="update" active="false" allportletsallowed="true" content-parentref="6_000000000000000000000000A0" create-type="explicit" domain="rel" objectid="6_CGAH47L0082M302B566VO730M6" ordinal="350" type="page" uniquename="wps.Login">
and: -
<content-node action="update" active="false" allportletsallowed="true" content-parentref="6_000000000000000000000000A0" create-type="explicit" domain="rel" objectid="6_CGAH47L0082M302B566VO730E2" ordinal="1400" type="page" uniquename="wps.Selfcare">
Finally, I imported the now-edited /tmp/Login_Selfcare.xml file into the portal, again using XMLAccess as follows: -
./xmlaccess.sh -in /tmp/Login_Selfcare.xml -url http://portaldemo.uk.ibm.com:10040/wps/config -user wpsadmin -password wpsadm1n
C'est voila, the links are no longer displayed in the theme.
Note that I did NOT need to stop/start the portal server; merely reloading the login page.
The benefit of taking a backup of the Login_Selfcare.xml file is that I can very easily switch Self-Care back on by running the import again: -
./xmlaccess.sh -in /tmp/Login_Selfcare.xml.BACKUP -url http://portaldemo.uk.ibm.com:10040/wps/config -user wpsadmin -password wpsadm1n
Note that I'm currently using the PortalWeb2 theme and the default DoubleTopNav theme policy, but this approach should work for the currently active theme.
5 comments:
Nice!!! This solves something that was flagged with a recent audit of our portal.
Well, I'm glad to be of service, Andrew. Many thanks for the feedback, Dave
Sorry, but I am not getting it. This script seems to disable wps.Login and wps.Selfcare Pages. I just tried this out and it really happened.
So as a result after executing this script my standard portal login page is not available anymore. But I expected only he "Register" Link in the upper right would be disabled.
Did I get this wrong ?
@marneum, nope, I've just gone back through the same process, and also find that the login page is disabled. I'm using WebSphere Portal Server 6.1.5 ( aka 6.1.0.3 ), so assume that something has changed between 6.1.0.2 and 6.1.0.3.
@Dave, thanks for the reply. I am happy you can reproduce it on 6.1.5.
Post a Comment