WikiSh Installation & Configuration

Obsolete Wikish is no longer supported nor maintained and does not work with modern versions of PHP.

Installation & Configuration of WikiSh

This page gives more detailed installation & configuration instructions for WikiSh.

  1. Download WikiSh.zipΔ
  2. Unzip and place WikiSh.php, WikiShCL.php, and SecLayer.php in your cookbook folder (usually pmwiki/cookbook)
    • Toolbox gives additional capabilities to WikiSh.php and it's a good idea to install that as well. (Without toolbox you cannot redirect standard output to a PTV and your RC files will not be processed for include, if, and comment directives.)
    • If you install Toolbox you should place that include command ahead of the other WikiSh.php, WikiShCL.php, SecLayer.php, etc. But it should be placed after any redefinitions of the pagestore or including scripts/xlpage-utf-8.php.
    • Note that if you do not install toolbox.php (or anywhere in config.php before toolbox.php is included) you cannot rely on the value of $pagename.
  3. Install in config.php and SiteAdmin.WikiShAuth as follows (note that SecLayer.php should be included after any customizations relating to stdconfig.php):

WikiSh is very configurable and takes security very seriously and as a result your installation options are numerous and flexible. We'll start with 6 example configurations (A-F) to give you an idea by example (if you want to go to one directly, I recommend the final one, F):

  1. If you want non-admins to have no write privileges and admins to have write privilege only in the WikiSh.* group and read privilege on everything (and everyone to have access to WikiSh functionality without read/write privileges):
include_once("$FarmD/cookbook/toolbox.php"); // place this as early as possible in config.php
include_once("$FarmD/cookbook/WikiSh.php");
if (CondAuth($pagename,'admin')) {
   $EnableWikiShWritePage = true;     // allow admins to write to pages (1st layer of security)
   $EnableWikiShCreatePage = true;    // allow admins to create new pages (2nd layer, part A)
   $EnableWikiShOverwritePage = true; //allow admins to overwrite existing pages (2nd layer, part B)
   include_once("$FarmD/cookbook/SecLayer.php");
   slParsePage($pagename, "SiteAdmin.WikiShAuth", $wshAuthPage);
}

In SiteAdmin.WikiShAuth you would put something like this (giving full access to WikiSh.* and only read access to *.*):

WikiSh.*:append,prepend,insert,overwrite,create,delete
*.*:read
  1. If you wanted to give general write privilege to your administrators then you could do something like this instead (and everyone to have access to WikiSh in a read-only capacity):
include_once("$FarmD/cookbook/toolbox.php"); // place this as early as possible in config.php
include_once("$FarmD/cookbook/WikiSh.php");
include_once("$FarmD/cookbook/SecLayer.php");
if (CondAuth($pagename,'admin')) {
   include_once("$FarmD/cookbook/WikiShCL.php");
   $EnableWikiShWritePage = true;     // allow admins to write to pages (1st layer of security)
   $EnableWikiShCreatePage = true;    // allow admins to create new pages (2nd layer, part A)
   $EnableWikiShOverwritePage = true; //allow admins to overwrite existing pages (2nd layer, part B)
   slParsePage($pagename, "SiteAdmin.WikiShAuth", $wshAuthPage);
}
slAddAuth($wshAuthPage, '*.*', 'read'); // add read privilege for everyone on all files

In SiteAdmin.WikiShAuth you would have something like this:

*.*:append,prepend,insert,overwrite,create,delete
  1. If you wanted to give no WikiSh capabilities whatsoever to non-admins and broad write privileges to admins then you could do something like this instead:
include_once("$FarmD/cookbook/toolbox.php"); // it is best to place this as early as possible in config.php
if (CondAuth($pagename,'admin')) {
   include_once("$FarmD/cookbook/WikiSh.php");
   include_once("$FarmD/cookbook/WikiShCL.php");
   $EnableWikiShWritePage = true;     // allow admins to write to pages (1st layer of security)
   $EnableWikiShCreatePage = true;    // allow admins to create new pages (2nd layer, part A)
   $EnableWikiShOverwritePage = true; // allow admins to overwrite existing pages (2nd layer, part B)
   $EnableWikiShChmod = true;         // allow admins to change pmwiki authorizations (aka action=attr) on pages
   include_once("$FarmD/cookbook/SecLayer.php");
   slParsePage($pagename, "SiteAdmin.WikiShAuth", $wshAuthPage);
}

In SiteAdmin.WikiShAuth you would have something like this:

*.*:append,prepend,insert,overwrite,create,delete,read
  1. If you wanted to give no WikiSh capabilities whatsoever when someone is on a page outside the WikiSh group but still give full capabilities to admins when they are on pages within the WikiSh group:
include_once("$FarmD/cookbook/toolbox.php"); // place this as early as possible in config.php
if ($Group == 'WikiSh' && CondAuth($pagename,'admin')) {
   include_once("$FarmD/cookbook/WikiSh.php");
   $EnableWikiShWritePage = true;     // allow admins to write to pages (1st layer of security)
   $EnableWikiShCreatePage = true;    // allow admins to create new pages (2nd layer, part A)
   $EnableWikiShOverwritePage = true; //allow admins to overwrite existing pages (2nd layer, part B)
   $EnableWikiShChmod = true;         // allow admins to change pmwiki authorizations (aka action=attr) on pages
   include_once("$FarmD/cookbook/SecLayer.php");
   slParsePage($pagename, "SiteAdmin.WikiShAuth", $wshAuthPage);
}

In SiteAdmin.WikiShAuth you would have something like this:

*.*:append,prepend,insert,overwrite,create,delete,read
  1. If you wanted to give no WikiSh capabilities whatsoever when someone is on a page outside the WikiSh group but still give full capabilities to admins inside the WikiSh group INCLUDING access (read and write) to text files in pmwiki/foo directory (and including the possibility of having a command line form on the ControlPanel page - highly recommended for administrating!):
include_once("$FarmD/cookbook/toolbox.php"); // place this as early as possible in config.php
if ($Group == 'WikiSh' && CondAuth($pagename,'admin')) {
   include_once("$FarmD/cookbook/WikiSh.php");
   if ($pagename == 'WikiSh.ControlPanel')
      include_once("$FarmD/cookbook/WikiShCL.php");
   $EnableWikiShWritePage = true;     // allow admins to write to pages (1st layer of security)
   $EnableWikiShCreatePage = true;    // allow admins to create new pages (2nd layer, part A)
   $EnableWikiShOverwritePage = true; // allow admins to overwrite existing pages (2nd layer, part B)
   $EnableWikiShTextWrite = true;     // allow writing to text files
   $EnableWikiShTextRead = true;      // allow reading of text files
   $EnableWikiShChmod = true;         // allow admins to change pmwiki authorizations (aka action=attr) on pages
   include_once("$FarmD/cookbook/SecLayer.php");
   slParsePage($pagename, "SiteAdmin.WikiShAuth#page", $wshAuthPage);
   slParsePage($pagename, "SiteAdmin.WikiShAuth#text", $wshAuthText);
}

In SiteAdmin.WikiShAuth you would have something like this:

[[#page]]
*.*:append,prepend,insert,overwrite,create,delete,read

[[#text]]
foo/*:append,prepend,insert,overwrite,create,delete,read

  1. RECOMMENDEDAll users will be able to make use of WikiSh and will have read access to all files and limited write access to pages in the Test group. Admins will have full WikiSh capabilities.
include_once("$FarmD/cookbook/toolbox.php");
include_once("$FarmD/cookbook/WikiSh.php");
include_once("$FarmD/cookbook/WikiShCL.php");
include_once("$FarmD/cookbook/SecLayer.php");
$EnableWikiShWritePage = true;
$EnableWikiShCreatePage = true;
$EnableWikiShOverwritePage = true;
if (CondAuth($pagename, "admin")) {
   slAddAuth($wshAuthPage, "*.*", "read,create,insert,overwrite,append,prepend,attr,delete");
   $EnableWikiShDeletePage = true;
   $EnableWikiShChmod = true;
} else {
   slAddAuth($wshAuthPage, "*.*", "read,create");
   slAddAuth($wshAuthPage, "Test.*", "insert,overwrite,append,prepend,delete");
}
include_once("$FarmD/cookbook/powertools.php");
include_once("$FarmD/cookbook/MiscMX.php");

The configuration above, when placed in your config.php, is sufficient to start using WikiSh. If you want to further utilize the capabilities of SecLayer.php with this recommended configuration, then read on below...

If you wanted to be able to manipulate your page authorizations by editing a page rather than through direct editing of the config.php you would use this code in config.php (in place of that above):

include_once("$FarmD/cookbook/toolbox.php");
include_once("$FarmD/cookbook/WikiSh.php");
include_once("$FarmD/cookbook/WikiShCL.php");
include_once("$FarmD/cookbook/SecLayer.php");
$EnableWikiShWritePage = true;
$EnableWikiShCreatePage = true;
$EnableWikiShOverwritePage = true;
slParsePage($pagename, "SiteAdmin.WikiShAuth#aliases", $wshAuthPage);
if (CondAuth($pagename, "admin")) {
   slParsePage($pagename, "SiteAdmin.WikiShAuth#admin", $wshAuthPage);
   $EnableWikiShDeletePage = true;
   $EnableWikiShChmod = true;
} else {
   slParsePage($pagename, "SiteAdmin.WikiShAuth#NONadmin", $wshAuthPage);
}
include_once("$FarmD/cookbook/powertools.php");
include_once("$FarmD/cookbook/MiscMX.php");

And then you would need to place this text in the page SiteAdmin.WikiShAuth:

[[#aliases]]
edit = append,prepend,insert,overwrite,create
full = edit, read
all = edit, delete, read, attr

[[#admin]]
*.*:all

[[#NONadmin]]
*.*:read
Test.*:edit
  1. Take special note of the security section below. WikiSh is a sharp tool enabling you to get the job done, but you can also "cut your hand" with that same sharp tool if you are not very careful. The warnings in that section must be carefully noted. DO NOT GIVE WRITE PRIVILEGE TO ANYONE YOU DO NOT TRUST! A malicious user given inappropriate write permissions could cause a lot of damage with WikiSh.
  2. (optional) Create a page (recommended: WikiSh.ControlPanel) containing the markup (:wikish_controlpanel:). A page like this is not a necessary part of installation, but it is the recommended way to work with WikiSh. Note that you will need cookbook/WikiShCL.php to be included for that page - if you want this markup always available then you can include this line in your config.php:
   include_once("$FarmD/cookbook/WikiShCL.php");

If you only want it to be included on a single page (such as WikiSh.ControlPanel) then you could use this instead (be sure you have previously included toolbox.php or in some other way resolved $pagename):

   if ($pagename == 'WikiSh.ControlPanel')
      include_once("$FarmD/cookbook/WikiShCL.php");
  1. Optionally set various $EnableWikiSh... variables to true or false (various suggested configurations of these variables can be seen above in 3.A-D:
VariableDescriptionDefault
$EnableWikiShWritePagegives permission to write to any wiki page allowed via $WikiShWriteList (see below). If this is set to false then NO pages will be allowed to be written. Note that either $EnableWikiShCreatePage or $EnableWikiShOverwritePage or both must be set to true as well to actually allow the possibility of writes to occur.true
$EnableWikiShCreatePagegives permission to create new wiki pages (requires $EnableWikiShWritePage and still will only work within the restrictions of $WikiShWriteList)true
$EnableWikiShOverwritePagegives permission to overwrite an existing page (requires $EnableWikiShWritePage and still will only work within the restrictions of $WikiShWriteList)true
$EnableWikiShRemovegives permission to delete files (requires $EnableWikiShWritePage AND $EnableWikiShOverwritePage)false
$EnableWikiShRemoveFullygives permission to fully delete files (requires $EnableWikiShRemove)false
$EnableWikiShTextReadgives permission to read text files (as opposed to wiki pages) (Beware!)false
$EnableWikiShTextWritegives permission to write text files (as opposed to wiki pages) (Beware!)false
$EnableWikiShPlayNicelyrenames all WikiSh MX names with a "wikish_" prefix (i.e., cat becomes wikish_cat, cp becomes wikish_cp, etc.) (Obviously if the name already begins with wikish then that MX name will not be renamed - it's already playing nicely.) (Note that control structures within {(wikish ...)} such as if/then/else/fi and while/do/done are NOT MX commands but rather implemented internally to wikish. Since there's no possibility of these causing name conflicts they are NOT renamed.) NOTE: This setting must be made BEFORE including WikiSh.php -- all other settings can be made either before or after the inclusion.false
$EnableWikiShChmodmakes the chmod MX active -- if false it will never do anythingfalse
$EnableWikiShMailxmakes the mailx MX active -- if false it will never do anythingfalse
$EnableWikiShEchoRawallow the --raw option in the echo MX. This is a security risk and should normally only be turned on for a specific debugging need and then turned back off.
  1. Set up SecLayer appropriately
    • See SecLayer for more details
    • If you have already copied one of the above 6 configuration options then you have already accomplished the purpose of this section and you can go on to #8. If you want more details on SecLayer security then read on further here.
    • In config.php you must...
      • have included SecLayer.php and...
      • have created the $wshAuthPage variable (and optionally the $wshAuthText variable) via calls to slParsePage() and/or slAddAuth()
        • often this will involve creating an appropriate page in the SiteAdmin group. There is nothing magic about the page SiteAdmin.WikiShAuth, but that is the preferred location. If your configuration needs require greater flexibility or etc feel free to set up your SecLayer page elsewhere or in multiple pages.
        • note that calls to slParsePage() and slAddAuth() can be intermixed freely. You can call each of these functions as many times as you want without difficulty.
      • A typical config.php in this section might look like this:
   include_once("$FarmD/cookbook/SecLayer.php");
   $pagename = ResolvePageName($pagename); // this is unnecessary if you have already included cookbook/toolbox.php
   slParsePage($pagename, "SiteAdmin.WikiShAuth#page", $wshAuthPage);
   slParsePage($pagename, "SiteAdmin.WikiShAuth#text", $wshAuthText);
  • Then you must have the page created that slParsePage() will read. In this case (above) you have specified SiteAdmin.WikiShAuth as the page and you have 1 section (#page) for the page authorizations and another section (#text) for the text authorizations. This page (SiteAdmin.WikiShAuth) could look something like this:
(:linebreaks:)
[[#page]]
edit = append,prepend,overwrite,insert,create
all  = edit,delete,attr,read
*.*:read
Test.*:all
WikiSh.*:edit
[[#text]]
edit = append,prepend,overwrite,insert,create
all  = edit,delete,read
mydir/hisdir/herdir/*:all
  • Or, if you prefer to do the work entirely in config.php rather than relying on a page and slParsePage() (note that aliases such as "edit" or "all" can be created only in slParsePage and so each authorization level must be explicitly declared here):
   include_once("$FarmD/cookbook/SecLayer.php");
   slAddAuth($wshAuthPage, "*.*", "read");
   slAddAuth($wshAuthPage, "Test.*,WikiSh.*", "insert,append,prepend,overwrite,delete");
   slAddAuth($wshAuthPage, "Test.*", "attr");

  • SecLayer does not specify what the authorization layers are, but WikiSh honors the following 10 possible authorizations:
    • append -- allow lines to be appended to the end of a page
    • prepend -- allow lines to be prepended before existing lines on a page
    • insert -- allow lines to be inserted between other lines on a page (nothing is deleted)
    • overwrite -- allow a page or a section of a page to be overwritten
    • create -- allow a new page to be created
    • read -- allow a page to be read
    • delete -- allow a page to be deleted
    • attr -- allow the passwords on a page/group to be changed (used only in chmod)
    • forceread -- override PmWiki 'read' authorization (allow read) (use with care and only enable on pages which are edit-protected)
    • forceedit -- override PmWiki 'edit' authorization (allow edit) (use with care and only enable on pages which are edit-protected)
  • Aliases such as "edit" and "all" and "none" are entirely at your discretion. You can name your aliases Bob & Larry if you want, but normally a more meaningful name is helpful. :-)

SecLayer also supports the concepts of priority and specific users (within authuser context). See SecLayer for more details.

  1. Optionally set other configuration variables below:
    • $wshPmAuthList (default: array('read', 'edit', 'attr', 'upload')
      • This array controls which types of passwords chmod will be able to set. If you password-protect other actions then you can add to this list. If you want chmod to be available but you want to limit it to not change certain passwords then you can take away from the list.
    • $WikiShControlPage (default: WikiSh.Control)
      • Set to a page-name (without group to default to current group) which will be used for the static repository for the once command
    • $WikiShSessionPagePat (default: array("/^session\./i", "/^virtual\./i", "/^temp\./i") )
      • Specify which groups will be automatically used for virtual memory-based files rather than "real" (disk-based, PmWiki-accessible) pages.
  2. Optionally set $WikiShVars variables (defaults are listed with comments pretty much verbatim from the code - if it's not clear what it does then just ask in WikiSh-Talk or drop me an email):
$WikiShVars['ACTIVE']       = true;
$WikiShVars['HIST_PREFIX']  = "(:linebreaks:\n");
$WikiShVars['FAVSFILE']     = "Favorites"; // default to current group
$WikiShVars['HISTFILE']     = "History";   // default to current group
$WikiShVars['HISTSIZE']     = 100;
$WikiShVars['NOHIST']       = false;
$WikiShVars['AUTHOR']       = "WikiSh";    // default author
$WikiShVars['DEFAULT_DEBUG']= 5; // Print debug statements of this level
                                 // and below. 1=detailed ... 5=nothing
$WikiShVars['DEBUGLEVEL']   = $WikiShVars['DEFAULT_DEBUG'];
$WikiShVars['DEBUG_OD']     = false;  // true=use wshDbgOd() (SLOWS EVERYTHING!)
$WikiShVars['RC_DEBUG']     = 5;      // normally no debug during RC
$WikiShVars['RANDOM_MIN']   = 0;      // default minimum for random
$WikiShVars['RANDOM_MAX']   = 32768;  // default maximum for random
$WikiShVars['PAGEVARS']     = 'post'; // "pre" "post" "prepost" "postpre"
$WikiShVars['LIST']         = '';     // like pagelist's list=X -- normal, etc.
$WikiShVars['SECONDS_START']= microtime(true;
$WikiShVars['SECONDSLEFT_START']= microtime(true;
  1. You may want to place (:messages:) somewhere on your pages with WikiSh commands (it is already included in the control panel) to get error feedback (and debugging, unfortunately, if I forget to turn it off)...

Security:

SECURITY NOTE on writing: If any write permission (whether wiki pages or text files) is given through the above $Enable... variables then it is strongly recommended to make this recipe available only on pages/groups which are password protected. SecLayer mitigates the threat to some degree, but you still need to be careful.

SECURITY NOTE on text reading: If you allow text file reading ($EnableWikiShTextRead = true;), it is STRONGLY recommended to make this recipe available only on pages/groups which are password protected and/or to be exceedingly careful in your setting of the $wshAuthText variables (in the SecLayer setup). If you are not careful imagine the output of this MX: {(grep DefaultPassword TEXTFILE--local/config.php)}!!!

Textfile access, whether reading or writing, should be used only with great caution. When accessing text files your access is limited only by the SecLayer restrictions and then the OS level file permissions. Unless you really know what you are doing you should not use this feature (textfile reading & writing).

SECURITY NOTE on forceread and forceedit: If you enable forceread or forceedit it must be from a page editable only by trusted authors. Otherwise undesired reads could be obtained or undesired page changes on pages that otherwise would be protected in this way. These "force" modes are very specific tools to be used with great care and only enabled on protected pages. Unless you really know what you are doing you should not use this feature.

The default installation of WikiSh (if no changes are made to any $EnableWikiSh___ variables and no calls are made to slAddAuth() nor slParsePage) does not allow any writing to any page. Normally WikiSh will either be installed in this read-only mode or else giving administrators write authorization but not non-admin editors (or perhaps giving non-admin editors write authorization to just a few specific pages or groups). Giving broader write permissions to non-admin personnel opens you up to potential risk as significant damage can be done in a very short time via WikiSh.

Security Levels

Recognizing the potential risk a scripting language presents in a collaborative environment such as a wiki page, WikiSh implements 4 different layers of security, particularly for write authorization to pages. ALL layers must be passed for a given page write. If a single layer is not passed then the write operation will not be allowed.

  • LAYER 1: PmWiki has a fairly comprehensive set of authorizations built in and these have been expanded by various other recipes. WikiSh always enforces authorizations set by PmWiki (unless an administrator has specifically enabled a "forceread" or "forceedit" authorization for a given page). If a user wouldn't be able to hit the "edit" button and make a change on a given page then they won't be able to write to that page through WikiSh. (This layer of security is implemented through operating system file permissions for text file access.)
  • LAYER 2: ALL writing can be turned on or off with one "switch" which is the $EnableWikiShWritePage variable. If it is set to false then WikiSh will never write to any page. If it is set to true then this layer will be passed. (This layer is implemented for text files both for reading and writing through the $EnableWikiShTextRead and $EnableWikiShTextWrite. The default is for both of these to be false.)
  • LAYER 3: Writing can be broken down into 2 types: either changing existing pages or creating new pages. Authorization to do either of these activities can be turned on or off with the variables $EnableWikiShCreatePage and $EnableWikiShOverwritePage. If they are set to true then the respective authorization is given; if set to false then this layer of security will not be passed. (This layer does not exist for text file access.)
  • LAYER 4: The administrator can configure a fine degree of control using the capabilities of SecLayer (slParsePage(), slAddAuth(), etc.)

The following are some possibilities available for configuration using SecLayer (each example will be given from a config.php perspective and then from a SiteAdmin.WikiShAuth page perspective -- the administrator can choose how he/she wishes to configure the site. In each example on the SiteAdmin.WikiShAuth side (i.e., doing it via page and not via config.php) it is assumed that there is a call such as this within config.php):

$pagename = ResolvePageName($pagename);  // this is unnecessary if you have already included cookbook/toolbox.php
slParsePage($pagename, "SiteAdmin.WikiShAuth", $wshAuthPage);
  • Only write to WikiSh group, read any page:
slAddAuth($wshAuthPage, 'WikiSh.*', 'insert,create,overwrite,append,prepend');
slAddAuth($wshAuthPage, '*.*', 'read');
edit=insert,create,overwrite,append,prepend
WikiSh.*:edit
*.*:read
  • Let's broaden it to allow some testing on the Test group as well:
slAddAuth($wshAuthPage, 'WikiSh.*,Test.*', 'read,insert,create,overwrite,append,prepend');
slAddAuth($wshAuthPage, '*.*', 'read');
edit=insert,create,overwrite,append,prepend
WikiSh.*:edit
Test.*:edit
*.*:read
  • In this example you can write to the WikiSh group, the Test group, and the Finance group, but not to the Finance.MySalary page:
slAddAuth($wshAuthPage, 'WikiSh.*,Test.*,Finance.*,-Finance.MySalary', 'read,insert,create,overwrite,append,prepend');
edit=insert,create,overwrite,append,prepend
WikiSh.*,Test.*,Finance.*:read,edit
Finance.MySalary:-read,-edit

Note that the dash can be placed either in front of the page/wildcard or in front of the authorization. Whether the authorization is an alias or a core authorization is irrelevant - it all just works. So you could have put the whole AuthPage in a single line and you could have separated the slAddAuth() code up into several different lines. The following are all functionally identical to this last example:

insert,create,overwrite,append,prepend
WikiSh.*,Test.*,Finance.*,-Finance.MySalary:read,edit
edit=insert,create,overwrite,append,prepend
AllButDelete = read,edit
none=-read,-edit
WikiSh.*,Test.*,Finance.*:AllButDelete
Finance.MySalary:none
edit=insert,create,overwrite,append,prepend
WikiSh.*,Test.*,Finance.*,-Finance.MySalary:read
WikiSh.*,Test.*,Finance.*,-Finance.MySalary:edit
  • In this example we delve into the "force" modes of WikiSh, a potentially dangerous area for administration. In this example I want a script which exists on page Test.Foo to be able to read from and write to SiteAdmin.PrivatePage which is (obviously) both read and edit protected via PmWiki authorizations (authorizations for other pages are ignored here):
$pagename = ResolvePageName($pagename);  // this is unnecessary if you have already included cookbook/toolbox.php
if ($pagename == 'Test.Foo')
   slAddAuth($wshAuthPage, 'SiteAdmin.PrivatePage', 'read,insert,create,overwrite,append,prepend,forceedit,forceread');

Note the "if" condition which prevents the "forceread" and "forceedit" capabilities being enabled for any other page other than Test.Foo. It is vital that Test.Foo be password protected from any edits!

Configuring SecLayer via a wiki authorization page is certainly possible in this instance, but it must be carefully coordinated with the necessary conditions in config.php. Here is what config.php might look like:

$pagename = ResolvePageName($pagename); // this is unnecessary if you have already included cookbook/toolbox.php
slParsePage($pagename, "SiteAdmin.WikiShAuth#aliases", $wshAuthPage);
slParsePage($pagename, "SiteAdmin.WikiShAuth#normal", $wshAuthPage);
if ($pagename == 'Test.Foo')
   slParsePage($pagename, "SiteAdmin.WikiShAuth#Test-Foo", $wshAuthPage);

Note again that all-important "if ($pagename == 'Test.Foo')" condition restricting the special "force" modes to that single page and the other all-important condition mentioned above that Test.Foo MUST be password protected for any edits.

And here is what SiteAdmin.WikiShAuth might look like to correspond with the above config.php section:

[[#aliases]]
edit=insert,create,overwrite,append,prepend
all=edit,read

[[#normal]]
... (whatever you might normally put in WikiSh permissions)

[[#Test-Foo]]
SiteAdmin.PrivatePage:all, forceread, forceedit

You can see that there is significant flexibility in how you configure your authorizations. Any authorization line you can place in your page (as above) can be expressed equivalently using slAddAuth() if you prefer working in config.php. The only thing you cannot do with slAddAuth() is to define aliases (you may use any aliases which you have already defined through a call to slParsePage()).

  • If this is for a password protected page or group (or if you like living dangerously) then you can give full permissions (delete and attr authorizations are still withheld, but you could easily add them):
slAddAuth($wshAuthPage, '*.*', 'read,insert,create,overwrite,append,prepend');
edit=insert,create,overwrite,append,prepend
*.*:read,edit
  • When dealing with text files (as opposed to wiki pages) you use the same methods of including/excluding files and the same authorization levels (excluding attr) but instead of $wshPageAuth you use $wshTextAuth. If you don't explicitly set it to something then it will not allow any reading/writing to text files.
  • Note that for both of these read/write list arrays a file MUST match at least one inclusive condition and must not match any exclusive conditions in order to match the condition.
  • SecLayer (slAddAuth() and slParsePage()) allow per-user permissions, different levels of priority for an inclusion/exclusion, etc. The information given above is just the simplest usage. See the SecLayer page itself for further capabilities.