Answered Questions (AQ)

Content from PmWiki.AccessKeys

Access keys (See also Wikipedia:access keys) are keyboard shortcuts for tasks that would otherwise require a mouse click. They are part of markup that may exist on any webpage. On PmWiki steps have been taken to make it easier to use access keys throughout a site, and to make it possible to adjust key assignments to accommodate different languages and preferences.

Using access keys in different operating systems and browsers

Access keys require you to hold down two or more keys.

• On Windows with Internet Explorer, press ALT + the access key.
• With Firefox, press SHIFT + ALT + the access key.
• On a Macintosh with Firefox, Omniweb, Internet Explorer, press Ctrl + the access key.
  • With Safari (Version 4.0.2) press Ctrl + Option + the access key.
• With Konqueror, press Ctrl to enter (or exit) access-key mode.
• With Chrome, press SHIFT + ALT + the access key
• access keys in Vivaldi

Exceptions exist for specific browsers, and specific versions. For example,

• Internet Explorer requires that the Enter key be pressed at the end of the sequence for versions 5 and up under Windows, but not under Macintosh (where access keys were not supported until after version 4.5).
• Firefox versions 1.5 and earlier simply use Alt, while Firefox version 2.0 uses Shift+Alt.

Note, in cases of conflicts between the keyboard shortcuts assigned by browsers and access keys assigned by links and other markup on webpages, many browsers, including Mozilla, Netscape and Internet Explorer, allow access keys to override the browser defaults and require a different sequence to continue using overridden browser assignments (typically, by pressing and releasing the Alt key, instead of holding it down).

Access key assignments in this PmWiki installation

The following is a list of the currently defined access keys for built-in actions. Remember that the letters identified below must be used together with the combination listed above (depending on your operating system and browser). Note that some actions do not have a corresponding access key by default.

When can these access keys be used

• Access keys ak_view, ak_edit, ak_history, ak_attach, ak_print, ak_backlinks, ak_logout and ak_recentchanges can be used all the time
• Access keys ak_save, ak_saveedit, ak_savedraft, ak_preview, ak_textedit can only be used in edit mode

Following table explains which button is activated by which access key. Note that the Cancel button has no access key.

• Access keys ak_em and ak_strong work only in edit mode and when the GUIbuttons are enabled in local/config.php.

admins (intermediate)

Customizing access keys

PmWiki uses the same "phrase translation" methods for access key mappings as it does for internationalization. This makes it possible for administrators, skins, language translators, and visitors to all influence the way that specific keys are mapped to actions.

See SitePreferences and Site.Preferences for more information and a template.

Note that some skins (e.g., Lean) don't use the translation mechanism. In this case one must edit the template file itself in order to change the access keys.

By convention, the translation phrases for all of the access key actions start with the characters "ak_", so that the page variable "$[ak_edit]" is replaced by the access key for editing as defined by the current preferences, language, skin default, or site default.

Implementation of access keys

Access keys are implemented in html as optional parameters that can be added to links and many other types of markup.

Example: <a href="https://example.com" accesskey="x">Example</a> would create a link to example.com that could be triggered by clicking on the linked word "example" or using the access key Akey+x. That same action key link could be created in PmWiki markup by typing %accesskey="x"%[[https://example.com|Example]]%%, like this: Example. Try it and see if it works. Note that this AKey+x access key only works this way on this page, because it is simply a shortcut for accessing the link that exists only on this page.

The list of access key assignments in default PmWiki installations generally work throughout a site because links have been created in PmWiki skins and editing screens that incorporate access key parameters using the access key translation phrases. One location where those links can be viewed is Site.PageActions. That page contains the links that the default PmWiki skin, and many other skins, use to generate links such as "View" "Edit" and "History" that appear on most pages (other than editing screens). Each of the links in that page also has an %accesskey=$[ak_xxx]% declaration in front of it, which enables a specific access key for that link.

Content from PmWiki.AccessKeys-Talk

• Discussion moved to PITS:01231 (Allow XLPage entries to have empty values).

Content from PmWiki.AdminTask

PmWiki Administration Tasks

This is a (experimental) list of all PmWiki administration related tasks that is organized in alphabetical order (and delimited by anchors so that it can be reused in other Wiki pages on this site). It is sort of based on core concepts of Darwin Information Typing Architecture (DITA) in which a topic is an archetype for information type. A topic is a unit of information that describes a single task, concept, or reference item. The information category (concept, task, or reference) is its information type (or infotype).

Tasks that are general in nature are on a different page. In DITA terms, AdminTask is a topic specialization of Task (which is a topic). Granted DITA is much more powerful and we cannot get all its benefits with PmWiki yet but perhaps one day, thanks to the genius of Pm, we can try and achieve more with every PmWiki release.

This page (meaning its URL) itself should NOT be linked to from anywhere but the sections should be included by using a syntax such as:

Administering Passwords

You can set passwords on pages and groups exactly as described above for authors. You can also:

1. set site-wide passwords for pages and groups that do not have passwords
2. use attr passwords to control who is able to set passwords on pages
3. use upload passwords to control access to the file upload capabilities (if uploads are enabled)
4. use an admin password to override the passwords set for any individual page or group

For more information on password options available to administrators, see PasswordsAdmin.

Installation

Setting Site Wide Passwords

One of the first things an admin should do is set an admin password for the site. This is done via a line like the following in the local/config.php file:

Note that the pmcrypt() call is required for this -- PmWiki stores and processes all passwords internally as encrypted strings. See the crypt section below for details about eliminating the cleartext password from the configuration file.

To set the entire site to be editable only by those who know an "edit" password, add a line like the following to local/config.php:

Similarly, you can set $DefaultPasswords['read'], $DefaultPasswords['attr'], and $DefaultPasswords['upload'] to control default read, attr, and upload passwords for the entire site. The default passwords are used only for pages and groups which do not have passwords set. Also, each of the $DefaultPasswords values may be arrays of encrypted passwords:

$DefaultPasswords['read'] = array(pmcrypt('alpha'), pmcrypt('beta'));
$DefaultPasswords['edit'] = pmcrypt('beta');

This says that either "alpha" or "beta" can be used to read pages, but only the "beta" password will allow someone to edit a page. Since PmWiki remembers any passwords entered during the current session, the "beta" password will allow both reading and writing of pages, while the "alpha" password allows reading only. A person without either password would be unable to view pages at all.

To generate an encrypted string from your cleartext password so that the cleartext doesn't appear in the config file, go right to

(add that to tail end of your address URL) for a form to use to encrypt the desired cleartext string into an encrypted string. Then simply copy the encrypted string and paste it in the config file where needed. --DP

Upgrading

To upgrade PmWiki:

• If you're upgrading to a new major release (a release where the second number changes, as in going from 0.5.27 to 0.6.0), then carefully read the PmWiki:ReleaseNotes before performing an upgrade to see if there are any significant changes or preparation tasks that must be handled before performing the upgrade. Upgrading from a beta version of 2.0 is quite easy, but taking a look at the 2.0 PmWiki:ReleaseNotes doesn't hurt.
• It's always a good idea to have a backup copy of your existing PmWiki installation before starting. You can copy the entire directory containing your existing installation, or you can just make copies of the wiki.d/ directory and any other local customization files you may have created (e.g., config.php, localmap.txt, etc.).
• Download the version of PmWiki that you want from https://www.pmwiki.org/pub/pmwiki.
• Read the Installation instructions
• Extract the tar image using tar -xvfz tgzfile, where tgzfile is the tar file you downloaded above. This will create a pmwiki-x.y.z directory with the new version of the software.
• Copy the files in pmwiki-x.y.z over the files of your existing PmWiki installation. For example, if your existing PmWiki installation is in a directory called pmwiki, then one way to copy the new files over the existing ones is to enter the command:

Note that Mac OS X and other BSD systems will not not have the -a option as a command-line argument for cp, but that's okay, since it's just shorthand for cp -dpR, so use that instead of -a.

On (some) FreeBSD servers you need to use

5. That's it! As long as you didn't make any customizations to the pmwiki.php script or to the files in scripts/, your PmWiki installation should continue to run correctly! (Local customizations should go in local/config.php)

Cleaning Up Deleted Files

When wiki pages are deleted, they leave behind residue as the deleted file isn't exactly deleted, but instead renamed to $FullName,del-TIMESTAMP. If you have a lot of deleted pages laying around, this builds up cruft in you file space. This is one method for cleaning up deleted pages.

Contributors:

BJayaram
tamouse

Content from PmWiki.AnalyzeResults

This page contains the instructions and possible responses from using the Site Analyzer.

Instructions for site administrators

1. Download the analyze.php script and place it in your site's cookbook/ directory.
2. Add the following lines to local/config.php, changing $AnalyzeKey to a key to use for your site.

   include_once("$FarmD/cookbook/analyze.php");
   $AnalyzeKey = 'secret';
   
3. Fill in the form at the top of the site analyzer page with the url used to access your site and the value of $AnalyzeKey that you set in local/config.php.
4. Press the "Analyze Site" button.
5. The PmWiki server will contact your site and report back with information on recommended configuration changes to your site and any vulnerabilities you may need to consider.

Checking the "Allow pmwiki.org to save a copy of analysis results" box will save a copy of the analyzer results in a private (web inaccessible) section of the pmwiki.org server. Having copies of results from many systems will help us to improve the analyzer and future configuration and security options for the PmWiki distribution.

Obtain site configuration ... no connection

The analyzer was unable to connect to the site. This may be because the url was entered incorrectly, the site is behind a firewall, or is otherwise inaccessible to the pmwiki.org server.

Obtain site configuration ... missing analyzer

The analyzer was able to reach the site, but the site did not respond to the ?action=analyze request. You may need to install the analyze.php script. This script should go in the cookbook/ directory, and then be enabled with

include_once("$FarmD/cookbook/analyze.php");
$AnalyzeKey = 'secret';

Obtain site configuration ... no key

The analyzer was able to contact the site, but the site does not appear to have an $AnalyzeKey set.

Obtain site configuration ... invalid key

The analyzer reached the ?action=analyze request, but the key entered did not match the $AnalyzeKey on the remote site.

Obtain site configuration ... update

A newer version of the analyze.php script is available -- you may wish to download it and re-run the analysis.

$FarmD register_globals vulnerability ... ok

Your site does not appear to have the $FarmD register globals vulnerability.

$FarmD register_globals vulnerability ... vulnerable

Your site appears to be vulnerable to the $FarmD register globals vulnerability. This vulnerability is being actively exploited in the wild, so you should do one of the following at the earliest opportunity:

• Upgrade to a version of PmWiki at least 2.1.22 or greater.
• Turn off register_globals in the php.ini or .htaccess file.

Recipe versions ... ok

All of the cookbook recipes active at this url appear to be up-to-date. Here's a list:

(:recipetable:)

Recipe versions ... check

There appear to be some new versions of cookbook scripts^* available. Here's a list:

* Note: Not all scripts reported here are necessarily installed. This list includes all PHP scripts in the cookbook directory, regardless of whether they are included via config.php or not. (PmWiki reports on all scripts in the cookbook directory because they may be conditionally included in certain configurations.)

AuthUser vulnerability ... ok

Your site does not appear to have the AuthUser vulnerability.

AuthUser vulnerability ... upgrade

Your site does not have the AuthUser vulnerability at the moment. You are, however, strongly encouraged to upgrade to PmWiki version 2.2.2 or later, as some future configuration of your hosting server might put you at risk.

AuthUser vulnerability ... probably vulnerable

Your site may be vulnerable to AuthUser vulnerability, if it relies on the core module AuthUser for User:Password authentication. This vulnerability may be actively exploited in the wild, so you should do one of the following at the earliest opportunity:

• Upgrade to a version of PmWiki at least 2.2.2 or greater.
• Turn on magic_quotes_gpc in the php.ini or .htaccess file.

?action=diag ... enabled

Your site is running with $EnableDiag set to 1, and others are able to perform ?action=diag on your pages to get diagnostic information about your site. While this isn't necessarily a bad thing (pmwiki.org does it), it can show a lot of configuration information that you might not want to be publicly available.

You may want to change local/config.php to have $EnableDiag=0 (PmWiki's default). A useful alternative to setting $EnableDiag in local/config.php is to set it in a per page customization, so that ?action=diag is enabled only on a single page instead of the entire site. To provide additional security use

$ScriptUrl setting ... relative

Your site has the $ScriptUrl variable set to a relative url -- i.e., without a leading http:// or https:// prefix. While this may appear to work in many situations, some web standards (e.g., web feeds and HTTP redirects) require the use of a fully-qualified (absolute) url. You may want to update your setting of $ScriptUrl to use an absolute url instead of a relative one.

If you want PmWiki to use relative urls for its internal page links, try the $EnableLinkPageRelative setting.

Content from PmWiki.AQ

This page is not a FAQ. It is just a repository for questions about PmWiki that have been answered. If you have asked a question about PmWiki and someone has given you the answer, please put them here. Then the next poor sod who has the same or similar question will at least have a chance of finding the answer on their own.

This page started in response to the following question.

Content from PmWiki.Audiences

This page contains Patrick Michaud's comments regarding the "audiences" for which PmWiki was designed. As such, many people are reluctant to modify the page, because it is a statement of his opinions and describes some of the thought that went into creating PmWiki. (And we all thank him for that!)

Patrick's comments

I think of PmWiki in terms of two audiences:

• Authors are the people who generate web content using PmWiki, and
• wiki administrators are the folks who install, configure, and maintain a PmWiki installation on a web server.

In some senses it could be claimed that as the primary developer of PmWiki I should only have wiki administrators as my target audience, and that authors are the target audience for the administrators. But what really makes PmWiki useful to wiki administrators is that I've put a lot of consideration into creating a tool that is usable by authors, so I have to keep the needs of both audiences in mind as I'm designing and adding new features to PmWiki.

Within the authoring audience I see that there are "naive authors" and "experienced authors".

"Naive authors" are the folks who use wiki to generate content but may know next-to-nothing about HTML, much less style sheets or PHP or the like. Naive authors are easily discouraged from generating web content if they have to wade through markup text that has lots of funny and cryptic symbols in them. So, if we want a site with lots of contributors, we have to be very careful not to do things that will cause this group to exclude themselves from participating.

"Experienced authors" are the folks who know a lot about HTML and could write their content as HTML, but have chosen to use wiki because of its other useful features (ease of linking, collaboration, ease of updates, revision histories, etc.) or because they want to collaborate with naive authors. Experienced authors usually don't have any problem with documents with lots of ugly markup in them; after all, they already know HTML. Experienced authors are sometimes frustrated with wiki because it doesn't have markup that would let them do something they know they can do in HTML (e.g., tables, stylesheets, colored text, etc.). And, they sometimes have difficulty understanding why naive authors would turn away from documents that have lots of markup sequences in them.

For the wiki administrator audience--the folks who install and may want to customize PmWiki--their backgrounds and goals are often quite diverse. PmWiki is designed so that it can be installed and be useful with minimal HTML/PHP knowledge, but it doesn't restrict people who know HTML/PHP from doing some fairly complex things. For one, PmWiki allows a site administrator to build-in markup sequences and features customized to his/her needs (and the needs of his/her audiences).

The separate needs of these audiences are behind most of the PmWikiPhilosophies. The people who develop PmWiki software must continually keep naive authors in mind as new features are requested and proposed by expert authors and Wiki Administrators. Sometimes it may seem to these latter groups that it's okay to implement the complex features because "naive authors don't have to use them", but the truth is that if complex/ugly markup sequences are available then they will eventually be used by someone, and once used they become a barrier to the naive authors. So, if I see that a feature could become a barrier to a naive author I don't include it in the base implementation of PmWiki, but instead find ways to let Wiki Administrators include it as a local customization.

Content from PmWiki.AuthoringPhilosophy

Patrick Michaud on the reasons behind Author variables:

I have trouble with the idea that PmWiki can automatically designate the "original author" -- many times pages are created as simple placeholders, which other authors then come and fill in. So, I think $Creator is probably better name than $Author for this, if we were to add it. But overall I think it's a mistake to try to get PmWiki to automatically determine "primary" authorship. Sometimes pages are completely reworked; and some authors will start deleting and re-posting pages just so they can get a perceived status or ego associated with some "primary author" designation. I think it's better if the appropriate credits for contributions appear in the content (either as prose, signatures, citations, or directives), than to have PmWiki impose a particular model on its authors.

Lastly, PmWikiPhilosophy #1 is "favor writers over readers", and somewhat fundamental to that concept is that any reader can also be an author, thus $Author instead of $User or $Reader. While I recognize this idea of "readers are authors" isn't universally true for many sites that will use PmWiki, as well as an extreme case of wishful thinking, the truth is that in PmWiki the only way someone gets a value into the $Author variable is to actually *be* an author.

(In case any are wondering, "authorship" and "identity" are two different things in PmWiki. The variable used to track the "reader" or login is $AuthId, and it really stands for "authenticated identity", as opposed to "author identity" or "author".)

Radu: The idea of 'readers as authors' is somehow negated by the existence of separate 'read' and 'edit' password sets.

I somewhat disagree. First, the 'read' password has nothing to do with this-- a read password doesn't separate a population into readers and authors, it separates them into readers and non-readers.

So, it's only the edit password that tends to separate things -- but even there, an edit password doesn't have to be site-wide. The edit password can be used (and often is used) simply to say "you can author any page on the site except the ones protected by this password". Generally the edit password is used as a security measure, not as a classification or caste system.

But in the final analysis, just because PmWiki promotes a particular view of the world doesn't mean it has to be totally consistent with it, or enslaved by it. In the "favor writers over readers" case, I'm rebelling against the traditional web maintenance architecture that limits pages to only one author (typically called the "webmaster"), and constrains everyone else to submitting their changes through that author. The philosophy isn't saying that everyone must be an author, it is saying that we should remove the barriers that prevent more people from becoming authors.

See also: Cookbook:PageCreator - recipe allowing to store, access and modify a Creator variable.

Content from PmWiki.AuthorTracking-Talk

I suggest that the PmWiki.AuthorTracking? page and Site.AllRecentChangesPerAuthor be deleted

Content from PmWiki.AuthUser

AuthUser is PmWiki's identity-based authorization system that allows access to pages to be controlled through the use of usernames and passwords. AuthUser can be used in addition to the password-based scheme that is PmWiki's default configuration.

AuthUser is a very flexible system for managing access control on pages, but flexibility can also bring complexity and increased maintenance overhead to the wiki administrator. This is why PmWiki defaults to the simpler password-based system. For some thoughts about the relative merits of the two approaches, see PmWiki:ThoughtsOnAccessControl.

See also: Cookbook:Quick Start for AuthUser.

Activating AuthUser

To activate PmWiki's identity-based system, add the following line to local/config.php:

Ensure that you have set a site wide admin password, otherwise you will not be able to edit SiteAdmin.AuthUser.

PmWiki caches some group and page authorization levels when a page is accessed. For this reason, it is better to include authuser.php quite early in config.php, notably

• after any recipe which inserts some custom writable PageStore class (MySQL, SQLite, Compressed PageStore or other)
• and after any internationalization (UTF-8 and XLPage).

(If you don't use a custom PageStore class and i18n, include authuser.php first thing in config.php.)

All other recipes should be included after these.

Creating user accounts

Most of AuthUser's configuration is performed via the SiteAdmin.AuthUser page. To change the AuthUser configuration, simply edit this page like any other wiki page (you'll typically need to use the site's admin password for this).

To create a login account, simply add lines to SiteAdmin.AuthUser that look like:

For example, to create a login account for "alice" with a password of "restaurant", enter:

When the page is saved, the "(:encrypt restaurant:)" part of the text will be replaced by an encrypted form of the password "restaurant". This encryption is done so that someone looking at the SiteAdmin.AuthUser page cannot easily determine the passwords stored in the page.

To change or reset an account's password, simply replace the encrypted string with another (:encrypt:) directive.

The password cannot contain spaces, tabs, new lines, colon ":" and equals "="; on some systems it should contain at least 4 characters. Usernames and passwords are case sensitive, eg. "User" is not the same as "user".

Controlling access to pages by login

Pages and groups can be protected based on login account by using "passwords" of the form id:username in the password fields of ?action=attr (see PmWiki.Passwords). For example, to restrict a page to being edited by Alice, one would set the password to "id:alice".

It's possible to use multiple "id:" declarations and passwords in the ?action=attr form, thus the following setting would allow access to Alice, Carol, and anyone who knows the password "quick":

    quick id:alice,carol

To allow access to anyone who has successfully logged in, use "id:*".

One can also perform site-wide restrictions based on identity in the $DefaultPasswords array (in local/config.php): e.g.

# require valid login before viewing pages
$DefaultPasswords['read'] = 'id:*';
# Alice and carol may edit
$DefaultPasswords['edit'] = 'id:alice,carol';
# All admins and Fred may edit
$DefaultPasswords['edit'] = array('@admins', 'id:Fred');

You can change the $DefaultPasswords array in local customization files such as:

• local/config.php (for entire wiki)
• farmconfig.php (for entire wikifarm)

Organizing accounts into groups

AuthUser also makes it possible to group login accounts together into authorization groups, indicated by a leading "@" sign. As with login accounts, group memberships are maintained by editing the SiteAdmin.AuthUser page. Group memberships can be specified by either listing the groups for a login account (person belongs to groups) or the login accounts for a group (group includes people). You can repeat or mix-and-match the two kinds as desired:

    @writers: alice, bob
    carol: @writers, @editors
    @admins: alice, dave

Then, to restrict page access to a particular group, simply use "@group" as the "password" in ?action=attr or the $DefaultPasswords array, similar to the way that "id:username" is used to restrict access to specific login accounts.

Excluding individuals from password groups

Group password memberships are maintained by editing the SiteAdmin.AuthUser page. To specify a password group that allows access to anyone who is authenticated, you can specify:

    @wholeoffice: *

If you need to keep "Fred" out of this password group :

    @wholeoffice: *,-Fred

To allow all users except Fred to change page attributes, for example, you can add to config.php :

Getting account names and passwords from other PmWiki pages

If you want PmWiki to get account names and passwords from other pages than SiteAdmin.AuthUser, you can set the variable $AuthUserPageFmt in config.php.

$AuthUserPageFmt must be set before including authuser.php.

Before PmWiki version 2.2.108, you can point PmWiki to an other page than SiteAdmin.AuthUser, like this:

    $AuthUserPageFmt = 'SomeOtherGroup.SomeOtherPage';

From PmWiki version 2.2.108 forward $AuthUserPageFmt can be an array of page names:

    $AuthUserPageFmt = array('SomeOtherGroup.SomeOtherPage', 'SomeThirdGroup.SomeThirdPage');

This will have AuthUser check in all listed pages, with the same expected format as documented. If there are repetitions, later values will replace previous ones.

Getting account names and passwords from external sources

The AuthUser script has the capability of obtaining username/password pairs from places other than the SiteAdmin.AuthUser page, such as passwd-formatted files (usually called '.htpasswd' on Apache servers), LDAP servers, or even the local/config.php file.

Passwd-formatted files (.htpasswd/.htgroup)

Passwd-formatted files, commonly called .htpasswd files in Apache, are text files where each line contains a username and an encrypted password separated by a colon. A typical .htpasswd file might look like:

    alice:vK99sgDV1an6I
    carol:Q1kSeNcTfwqjs

To get AuthUser to obtain usernames and passwords from a .htaccess file, add the following line to SiteAdmin.AuthUser, replacing "/path/to/.htpasswd" with the filesystem path of the .htpasswd file:

    htpasswd: /path/to/.htpasswd

Creation and maintenance of the .htpasswd file can be performed using a text editor, or any number of other third-party tools available for maintaining .htpasswd files. The Apache web server typically includes an htpasswd command for creating accounts in .htpasswd:

    $ htpasswd /path/to/.htpasswd alice
    New password:
    Re-type new password:
    Adding password for user alice
    $

Similarly, one can use .htgroup formatted files to specify group memberships. Each line has the name of a group (without the "@"), followed by a colon, followed by a space separated list of usernames in the group.

    writers: carol
    editors: alice carol bob
    admins: alice dave

Note that the groups are still "@writers", "@editors", and "@admins" in PmWiki even though the file doesn't specify the @ signs. To get AuthUser to load these groups, use a line in SiteAdmin.AuthUser like:

    htgroup: /path/to/.htgroup

Configuration via local/config.php

AuthUser configuration settings can also be made from the local/config.php file in addition to the SiteAdmin.AuthUser page. Such settings are placed in the $AuthUser array, and must be set prior to including the authuser.php script. Some examples:

# set a password for alice
$AuthUser['alice'] = pmcrypt('restaurant');
# set a password for carol
$AuthUser['carol'] = '$1$CknC8zAs$dC8z2vu3UvnIXMfOcGDON0';
# define the @editors group
$AuthUser['@editors'] = array('alice', 'carol', 'bob');
# Use local/.htpasswd for usernames/passwords
$AuthUser['htpasswd'] = 'local/.htpasswd';
# Use local/.htgroup for group memberships
$AuthUser['htgroup'] = 'local/.htgroup';

include_once("$FarmD/scripts/authuser.php");

Configuration via LDAP

Authentication can be performed via an external LDAP server -- simply set an entry for "ldap" in either SiteAdmin.AuthUser or the local/config.php file.

# use ldap.airius.com for authentication
$AuthUser['ldap'] = 'ldap://ldap.airius.com/ou=People,o=Airius?cn?sub';

Make sure to include AuthUser below the entry for the ldap server:

# Want to use AuthUser so we can use ldap for passwords
include_once("$FarmD/scripts/authuser.php");

And remember to assign the Security Variables for edit and history (or whatever):

#Security Variables set login for edit & history page
# to let anyone edit that has an ldap entry:
$HandleAuth['diff'] = 'edit';
$DefaultPasswords['edit'] = 'id:*';
$Author = $AuthId;

LDAP authentication in AuthUser closely follows the model used by Apache 2.0's mod_authnz_ldap module; see especially the documentation for AuthLDAPUrl for a description of the URL format.

For servers that don't allow anonymous binds, AuthUser provides $AuthLDAPBindDN and $AuthLDAPBindPassword variables to specify the binding to be used for searching.

See also Cookbook:AuthUser via Microsoft LDAP

Setting the Author Name

By default, PmWiki will use a login name in the Author field of the edit form, but allows the author to change this value prior to saving. To force the login name to always be used as the author name, use the following sequence in config.php to activate AuthUser:

include_once("$FarmD/scripts/authuser.php");
$Author = $AuthId; # after include_once()

To allow more flexibility, but still enable changes to be linked to the authorized user, one can give the author name a prefix of the $AuthId instead:

    include_once("$FarmD/scripts/author.php");
    include_once("$FarmD/scripts/authuser.php");
    if ($Author) {
	if (strstr($Author, '-') != false) {
	    $Author = "$AuthId-" . preg_replace('/^[^-]*-/', '', $Author);
	} else if ($Author != $AuthId) {
	    $Author = $AuthId . '-' . $Author;
	} else {
	    $Author = $AuthId;
	}
    } else {
	$Author = $AuthId;
    }
    $AuthorLink = "[[~$Author]]";

The above will allow the user to put in the author name of their choice, but that will always be replaced by that name prefixed with "$AuthId-". The reason why $AuthorLink needs to be set is that, if it isn't, the RecentChanges page will have the wrong link in it.

Removing the "Author" edit field

To force users to edit with their AuthID instead of having a field they can place any name in. This enables administration to keep track of who is doing what better. This line also links the Author name to their Profile.
Go to Site.EditForm, remove the line

or replace it with

Authorization, Sessions, and WikiFarms

PmWiki uses PHP sessions to keep track of any user authorization information. By default PHP is configured so that all interactions with the same server (as identified by the server's domain name) are treated as part of the same session.

What this means for PmWiki is that if there are multiple wikis running within the same domain name, PHP will treat a login to one wiki as being valid for all wikis in the same domain. The easiest fix is to tell each wiki to have use a different "session cookie". Near the top of a wiki's local/config.php file, before calling authuser or other recipes, add a line like:

session_name('XYZSESSID');

The XYZSESSID can be any unique name (letters only is safest). For the exact naming rules please lookup the description in the PHP manual for the PHP version you use on your server.

Security Reminder: Using different session names in cookies and/or URLs helps against inter-wiki confusion in a browser, but this is not a protection against session injection attacks on the server. See Cookbook:Session Security Advice for that.

See Also

• PmWiki.Passwords
• PmWiki.PasswordsAdmin
• Cookbook:AuthUser for tips and tricks
• SiteAdmin.AuthUser

FAQ

Content from PmWiki.AuthUser-Talk

This is a talk page for improving AuthUser.

farmconfig.php:
$AuthUser['htpasswd'] = 'path/to/.htpasswd';
$AuthUser['htgroup'] =  'path/to/.htgroup';
$DefaultPasswords['edit'] = '@wiki-editors';
#NO include of authuser.php here, while it will destroy all settings – correct?

wiki1/local/config.php:
$DefaultPasswords['read'] = '';
include_once("$FarmD/scripts/authuser.php");

wiki2/local/config.php:
$DefaultPasswords['read'] = '@wiki2-readers';
include_once("$FarmD/scripts/authuser.php");

(:if ! enabled AuthPw:)
* %item rel=nofollow class=login  accesskey='$[ak_login]'%   [-'''%color=#880000%[[{*$FullName}?action=login | $[Login] ]]%%'''-]
(:ifend:)
(:if enabled AuthPw:)
(:if2 auth admin:)
* [-[[Profiles.{$Author} | %color=#660000%'''''{$Author}''  - '''%%%color=#ff0000% ''Profile''%%]]-]
* %item rel=nofollow class=logout accesskey='$[ak_logout]'% [-'''''%color=#ff0000%[[{*$FullName}?action=logout | $[Logout] ]]%%'''''-]
(:else2:)
* [-[[Profiles.{$Author} | %color=#660000%'''''{$Author}''  - '''%%%color=#00ca00% ''Profile'' %%]]-]
* %item rel=nofollow class=logout accesskey='$[ak_logout]'% [-'''''%color=#00ca00%[[{*$FullName}?action=logout | $[Logout] ]]%%'''''-]
(:if2end:)
(:ifend:)
(:if auth admin:)
* [-[[Site/Site | %color=red%Site Admin%%]]-]
(:ifend:)
* [-[[Site.SiteMap | %color=#0000aa%Site Map%%]]-]

  $DefaultPasswords['edit'] = '@editors';

  @editors: Alice, Bob

  ## Preventing others posting as "Pm" or "Petko"
  if( preg_match('/^(Pm|Petko)$/i', trim(@$_POST['author'])) ){
    $DefaultPasswords['edit'] = '@lock';
    $MessagesFmt[] = "To post as '{$_POST['author']}' please log in.";
  }

 $AuthUser['htpasswd'] = '.htpasswd';
 $AuthUser['htgroup'] = '.htgroup';
 include_once('scripts/authuser.php');
 $Author = $AuthId;
 $DefaultPasswords['admin'] = 'id:Admin';

 $DefaultPasswords['edit'] = crypt('edit_password');
 $DefaultPasswords['read'] = crypt('read_password');
 $DefaultPasswords['admin'] = crypt('admin_password');
 $include_once("scripts/authuser.php");

  $postauthor = stripmagic(trim(@$_POST['author']));
  if( preg_match('/^(Pm|Petko)$/i', $postauthor) ){
    $DefaultPasswords['edit'] = '@lock';
    $MessagesFmt[] = sprintf("To post as '%s' you need to log in.", $postauthor);
  }

   !!Login accounts
   mierk: $1$8XR6Uzui$3pQn6AaB0nSaDldQ11Sjd1
   !!Authorization groups
   @admins: mierk

   !!Authorization groups
   @admins: mierk
   !!Login accounts
   mierk: $1$izeCyGE7$N7ZDdxfyI8jf/8bM/ZDoh/

wiki1-admins: tom petko peter 
wiki1-editors: garry mary sandy

wiki2-admins: @wiki1-admins rosie missie chrissie

Content from PmWiki.AvailableActions

Page actions are applied to wiki pages, as a query string appended to the URL. Security can be applied to all default actions, and script actions with one exception, but not diag actions, through the use of passwords.

Also documented are all other URL queries.

NOTE: All actions will be disabled if the following is set:

    $EnableActions = 0;
    include('pmwiki.php');

This will initialize PmWiki (along with any configuration/customizations that are being made, e.g. from local/config.php), but won't actually perform any actions. The caller can then call the desired action or other functions as desired. This is available from Version 2.2.0-beta22 on up.

PmWiki Actions

See also site page actions.

?action=attr

displays dialog for setting/changing password of the specified page or group of pages, see passwords, see also $EnablePostAttrClearSession if you do not want to have the session cleared after validating change General use of passwords and login

?action=browse

display the specified page (default action if no ?action= is present)

?action=crypt

displays a form for generating hashed passwords out of clear text for usage in your config.php

?action=diff

show a change history of the specified page, see page history History of previous edits to a page

?action=download&upname=file.ext

retrieve the page's attachment named file.ext, see $EnableDirectDownload

?action=edit

edit the specified page, see basic editing PmWiki's basic edit syntax

?action=login

prompt visitor for username/password, by default using Site.AuthForm

?action=logout

remove author, password, and login information

?action=print

display the specified page using the skin specified by $ActionSkin['print']

?action=refcount

bring up the reference count form, which allows the user to generate a list of links (all, missing, existing or orphaned) in or from specified groups. See Ref Count Link references counts on pages . Part of the core distribution but must be enabled by the administrator.

?action=search

displays searchbox on current page, see search Targeting and customizing search results

?action=search&q=searchterm

performs search with searchterm and displays results on current page

?action=search&q=link=pagename

performs backlinks search with pagename and displays results on current page

?action=source

show page source (plain text only)

?action=source&highlight=1

show page source highlighted (HTML output)

?action=template

creates a link that will open the NewPage using the contents of OldPage, see Cookbook:Edit Templates Specify a wiki page or pages to use as a template when a new page is created.

?action=atom

?action=rdf

?action=rss

?action=dc

If web feeds are enabled, returns a syndication feed based on the contents of the page or other options provided by the url, see web feeds Web feed notification of changes

?action=upload

display a form to upload an attachment for the current group, see uploads Uploading and linking to attachments

Query string parameters

?from=page name

use when a page is redirected

?n=page name

display page

?setprefs=SomeGroup.CustomPreferences

sets cookie to custom preferences page. See site preferences Customisable browser setting preferences: Access keys, edit form

Actions enabled by $EnableDiag

The following actions are available only if you set $EnableDiag = 1; in your configuration file. They can be used for debugging and should not be set in a production environment.

?action=ruleset

displays a list of all markups in 4 columns:

• column 1 = markup-name (1. parameter of markup() )
• column 2 = when will rule apply (2. parameter of markup() )
• column 3 = PmWiki's internal sort key (derived from #2)
• column 4 = Debug backtrace information for potentially incompatible rules (filename, line number, pattern)

?action=phpinfo

displays the output of phpinfo() and exits. No page will be processed

• doesn't make use of PmWiki's authorization mechanisms.

?action=diag

displays a dump of all global vars and exits. No page will be processed

• doesn't make use of PmWiki's authorization mechanisms.

Actions enabled by PmWiki Scripts

?action=analyze

see Site Analyzer and Analyze Results

?action=approvesites

see Url approvals Require approval of Url links

• doesn't make use of PmWiki's authorization mechanisms.

Actions enabled by recipes

(more information about Custom Actions)

?action=admin

see Cookbook:UserAuth2 A user-based permission granting and authentication module

?action=attachman

see Cookbook:Attachman Attachman[ager] shows attaches as a rich sortable table, works also via AJAX

?action=backup

see Cookbook:BackupPages Automatically back up the wiki.d directory to a .zip file

?action=clearsky

see Cookbook:SearchCloud Creates a list of search terms used on a PmWiki site.

?action=cm-dependencies

see Cookbook:CodeMirror An enhanced page editor for PmWiki

?action=comment

see Cookbook:CommentBox Adds a simple form to post comments

?action=comments

see Cookbook:Comments Comment addon - comments in separate files

?action=comment-rss

see Cookbook:CommentDb Comment recipe - with pagination and RSS feed

?action=convert

see Cookbook:ROEPatterns Replace On Edit

?action=converttable

Cookbook:ConvertTable Convert table action

?action=copy

see Cookbook:MovePage Move and copy wiki pages

?action=csv

see Cookbook:CSVAction Adds a ?action=csv capability to pmwiki to output tables as a CSV

?action=downloaddeleted

?action=delattach

?action=deldelattach

?action=fileinfo

?action=thumbnail

?action=undelattach

Cookbook:Attachtable Actions to rename, delete & restore deleted attachments, as well as an attachlist replacement to use those actions, show file types and list attachment references.

?action=delete

see Cookbook:DeletePage Use a "delete" action and a separate password for deleting pages

?action=discuss

see Cookbook:DiscussionTab Provide a skin with a "discussion" tab and "article" tab, etc.

?action=downloadman

see Cookbook:DownloadManager How can I know how many times a file was downloaded from my wiki?

?action=expirediff

see Cookbook:ExpireDiff How to remove a page's history

?action=hidediff

see Cookbook:HideDiff Hide specific edits from page histories

?action=hub

see Cookbook:ExtensionHub Configuration panel for extensions

?action=import

see Cookbook:ImportText Import text files as PmWiki pages

?action=lang

see Cookbook:MultiLanguageViews show language specific content and titles according to user choice

?action=setlang

see Cookbook:MultiLanguageViews show language specific content and titles according to user choice

?action=links

see Cookbook:RenamePage Rename a wiki page from a browser

?action=lockflipbox

see Cookbook:Flipbox Flippable checkboxes and checklists

?action=unlockflipbox

see Cookbook:Flipbox Flippable checkboxes and checklists

?action=migr8

see Cookbook:MigrateUTF8 Convert filenames of PmWiki pages and uploads to UTF-8

?action=move

see Cookbook:MovePage Move and copy wiki pages

?action=pageindex

see Cookbook:ListCategories use categories as tags

?action=PageUrl

see Cookbook:CommentBoxPlus Simple styled form to post comments, plus comment counter

?action=pdf

see Cookbook:GeneratePDF Generate PDF versions of pages (?action=pdf)

or Cookbook:PmWiki2PDF Generate a PDF; back up all wiki pages in PDF format

?action=postupload2

see Cookbook:UploadForm Alternative file upload form using (:input file:)

?action=ppdonate

see Cookbook:PPDonate - Create links to accept donations via PayPal

?action=publish

see Cookbook:PublishPDF Typesets wiki page collections into PDF (finalist: New Zealand open source awards 2008)

?action=purgeqns

see Cookbook:ASCIIMath Display MathML rendered ascii formula into PmWiki 2.x pages

?action=pwchange

see Cookbook:UserAuth2 A user-based permission granting and authentication module

?action=imgtpl

(the imgtpl action is called automatically and should not be called by a link in a wiki page)

?action=createthumb

(the createthumb action is called automatically and should not be called by a link in a wiki page)

?action=mini

(this action is called automatically and should not be called by a link in a wiki page)

?action=purgethumbs

see Cookbook:ThumbList A thumbnail picture gallery for PmWiki
see Cookbook:Mini Simple, lightweight, un-bloated gallery with thumbnail generator

?action=recipecheck

see Cookbook:RecipeCheck Check for new versions of recipes on pmwiki.org

?action=regen

see Cookbook:PageRegenerate Make PmWiki regenerate a page, as if someone had done an edit+save sequence.

?action=reindex

see Cookbook:Reindex Force re-creation of entire .pageindex

?action=reindexcat

See Cookbook:ReindexCategories Update link targets and page index for PmWiki 2.3.0

?action=rename

?action=links

see Cookbook:RenamePage Rename a wiki page from a browser

?action=rmpi

see Test.PageIndex This page exists to test and benchmark the page indexing facilities.

?action=share

?action=unshare

see Cookbook:SharedPages Share selected pages among several wikis on a common server, as in WikiFarms

?action=sitemap

see Cookbook:GoogleSiteMap Create an XML sitemap in the root of the website which is suitable for submission to Google (and other) search engines.

?action=sitemapaddgroups

?action=sitemapupdate

see Cookbook:Sitemapper Adds a dynamically generated sitemap to PmWiki.

?action=totalcounter

see Cookbook:TotalCounter A statistic counter - counts page views, users, languages, browsers, operating systems, referers, locations and web bots

?action=trash

?action=untrash

see Cookbook:Trash "safely delete" pages so that they can be restored and listed with pagelists

?action=webadmin

see Cookbook:WebAdmin PHP file manager, works without ftp client

?action=zap

see Cookbook:ZAP The ZAP forms processor handles data and file management, page insertions (forums, blogs), email & newsletters, e-commerce, and more.

Query string parameters enabled by recipes

?color=colorscheme

:?setcolor=colorscheme

?skintheme=theme

?setskintheme=theme

see Cookbook:ChoiceColorChanger Provide a way of setting persistent skin color and theme choices when using the Choice skin.

?skin=skinname

?setskin=skinname

see SkinChange change skin via query or cookie setting

Custom actions

• See CustomActions.

Content from PmWiki.AvailableActions-Talk

Here are the actions using the full linkage markup:

• Csv
• Downloaddeleted
• Delattach
• Deldelattach
• Fileinfo
• Thumbnail
• Undelattach
• Delete
• Discuss
• Downloadman
• Expirediff
• Import
• Move
• Pageurl
• Pageindex
• Pdf
• Postupload2
• Publish
• Purgeqns
• Pwchange
• Imgtpl
• Createthumb
• Mini
• Purgethumbs
• Recipecheck
• Regen
• Rename
• Links
• Share
• Unshare
• Sitemapaddgroups
• Sitemapupdate
• Totalcounter
• Trash
• Untrash
• Webadmin
• Zap