Skip to main content link. Accesskey S
  • IBM.com
  • WebSphere software
  • Machine Translation



Home > XML Access and Portal Scripting Interface > Portal script to list content node security

Portal script to list content node security

No abstract provided.
ShowTable of Contents
 

Introduction


 
From what I've seen, there are precious few samples of Portal scripts floating around out there.  Hopefully, this will not only add some value to your enterprise, but provide a foundation on which to build your own Portal scripts.

If you have a large number of pages and labels, and a complex security configuration in terms of groups and users, you might find this script handy.  Essentially, it allows you to feed in a unique name for a page/label (and virtual portal name), and will print out the user/group security configuration for that content node subtree.  This script does not list security for portlets that have been added to the pages, just for pages/labels themselves.  It's often handy to be able to see the entire security layout without clicking in and out of tens or hundreds of pages.  So, here goes...

This example was created on an AIX server, but can easily be adapted to other operating systems.  It assumes you know basic information about your Portal installation, such as file paths and ports (such as those used by xmlaccess).

We'll be dealing primarily with 3 files:

   1. The shell script that you execute (list_contentnodes.sh)
   2. The profile script that's used to log you in to Portal (wpscripter_login_vpname.jacl)
   3. The jacl file that accesses Portal and gets the information (list_contentnodes.jacl)

The files don't need to reside in a specific location, but in the configuration that follows, they all need to be in the same directory.  This can of course be modified to suit your own Portal environment.
 

Shell script


So, let's take a look at the contents of the shell script for starters:


#!/bin/ksh

portal_home="/usr/IBM/WebSphere/PortalServer"
${portal_home}/bin/wpscript.sh -port port_number -profile ./wpscripter_login_$1.jacl -f ./list_contentnodes.jacl $1 $2 $3



So, the format of the command with arguments is ./list_contentnodes.sh virtualportal_name contentnode_uniquename artifact_type
    • virtualportal_name - If you don't use virtual portals, you can adjust the script to omit this argument.  Otherwise, this is the virtual portal name ("base" is used for the base portal the is installed initially).
    • contentnode_uniquename - It's a good idea to use uniquenames for all artifacts.  This is the unique name for the page or label.
    • artifact_type - This will either be "page" or "label"
 

Profile script


Next is the profile script.  In this scenario, a profile script is created for each virtual portal.  You can of course log in to Portal inside the main jacl script.  However, the nice thing about profile scripts is that they can be reused for all of your other jacl scripts.

Here is the content of the profile script for the base portal (wpscripter_login_base.jacl).  Substitute your own username and password, such as the one you might use for xmlaccess.  You may choose to store and access the password by other means.  Regardless, you'll want to secure the profile script file appropriately.  If you choose not to utilize the username and password, my experience has been that it will use the login username and password values from the soap.client.props file for your profile.


$Portal login username password



Here is the content of a profile script for a virtual portal (e.g. wpscripter_login_vp999.jacl).


$Portal setvp vp999

$Portal login username password


 

Main jacl script


Finally, the jacl script that does all the work  (list_contentnodes.jacl)


set vp [lindex $argv 0]
set artifact_uniquename [lindex $argv 1]
set artifact_type [string tolower [lindex $argv 2]]
set current_time [clock format [clock seconds] -format "%Y%m%d_%H%M"]
set outfile [open "list_${vp}_${artifact_uniquename}_${current_time}.txt" w]

################################################################
proc log_it { log_message } {
   global outfile

   puts $log_message
   puts $outfile $log_message

   return
}

################################################################

switch $artifact_type {

  page {
    $Content find page uniquename $artifact_uniquename select
  }
  label {
    $Content find label uniquename $artifact_uniquename select
  }
  default {
    log_it "$artifact_type is not a valid artifact type - please use page or label as artifact type"
    exit
  }
}


log_it "------------------------------------------------------------------------------------"

foreach page [$Content search all] {
  $Content select $page

  set c_type "[$Content get type]"
  set c_uname "[$Content get uniquename]"
  set c_name "[$Content nlsget title en]"
  #set out_txt "$c_uname, $c_type"
  #log_it "$out_txt"
  log_it "Name: $c_name"
  log_it "Unique name: $c_uname"
  log_it "Type: $c_type"

  $PacList view [$Access getacl Content [$Content current]]

  # example: list all principals in all lists

  foreach as [$Access listall actionsets] {
    set out_aclist "[$PacList list $as all]"
    if {$out_aclist != ""} {
       set out_access "# $as:"
       log_it "   $out_access"

       # 0 = blocked, 1 = unblocked
       set out_inherit "[$PacList show $as inheritance numeric]"
       set out_propagate "[$PacList show $as propagation numeric]"
       if {$out_inherit == 0} {
          set out_i_flag "block"
          log_it "    ## inheritance $out_i_flag"
       }
       if {$out_propagate == 0} {
          set out_p_flag "block"
          log_it "    propagation $out_p_flag"
       }

       foreach acl $out_aclist {
          log_it "    
# $acl"
       }
       log_it " "
    }
  }

log_it "------------------------------------------------------------------------------------"
}
close $outfile
$Portal logout


 

Script output


Now for the output.  It's important to note that it helps to have a structured unique name scheme.  It will help to identify content node hierarchy much easier when viewing the output.  Let's say you type in the following command:

./list_contentnodes.sh sales company.department.sales.pg page

The output might look something like what's shown below.  Note that if you follow the unique names, you can see the content node hierarchy.  Another way of indicating hierarchy would be to indent...perhaps in an updated version of the script.

The script also writes the output to a log file, which might look something like this:  list_sales_company.department.sales.pg_20091208_1718.txt



Name: Main Sales Page
Unique name: company.department.sales.pg
Type: page
   # User:
    inheritance block
    
# cn=sales_associates,ou=users,o=company.com



Name: Retail Sales Division
Unique name: company.department.sales.retail.lb
Type: label


Name: Retail Clothing Sales Page
Unique name: company.department.sales.retail.clothing.pg
Type: page
   # PrivilegedUser:
     ### cn=retail_clothing_administrators,ou=users,o=company.com

   # Manager:
     ### cn=retail_clothing_managers,ou=users,o=company.com

   # User:
    inheritance block
    
# cn=retail_clothing_associates,ou=users,o=company.com




This Version: 9 December 17, 2009 2:06:19 PM by Victor Schaefferkoetter
Originally Added: Version 1 December 16, 2009 4:15:31 PM by Victor Schaefferkoetter