Menu | PmWiki / PasswordsAdmin | |
Downloads Installation Instructions Learning Java Documentation Tutorials Update Log Application Demos Publications People Project Roadmap Code of Conduct |
< Notify | Documentation Index | Ref count > administrators (basic)
PmWiki has built-in support for password-protecting various areas of the wiki site. Passwords can be applied to individual pages, to Wiki Groups, or to the entire wiki site. Note that the password protection mechanisms described here are only a small part of overall system (and wiki) security, see PmWiki.Security for more discussion of this. Authors can use PmWiki to add passwords to individual pages and WikiGroups as described in Passwords. However, WikiAdministrators can also set passwords in local/config.php as described below. (Please note that one cannot set passwords reliably in per group or per page customization files. See the FAQ section for details.) Password basicsPmWiki supports several levels of access to wiki pages, known as authorisation level:
By default, PmWiki has the following password settings:
An See Passwords for information about setting per-page and per-group passwords. The remainder of this page describes setting site-wide passwords from the local/config.php file. Setting site-wide passwordsOne of the first things an admin should do is set an $DefaultPasswords ['admin'] = pmcrypt('secret_password');
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: $DefaultPasswords ['edit'] = pmcrypt('edit_password');
Similarly, you can set a password for any available action, via $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 lock an action so that only admins can perform it, use $DefaultPasswords ['edit'] = '@lock';
Setting passwords by referenceThis is an unintended feature. Setting passwords by reference allows you to change the password for a whole set of pages as easily as you can change site-wide passwords. (Otherwise you would have to update each page's attributes individually.) Enter in the Page Attributes or Group Attributes: @_site_MyLevel2
And in the local configuration file set the actual password with lines like this: $DefaultPasswords ['MyLevel2'] = array(pmcrypt('secret'), '@admins');
$DefaultPasswords ['MyLevel9'] = array('$1$NuBV/Mcc$GG3J60h.TLczUTRKhoVPM.');
Note that passwords set by reference in a configuration file currently can not be used as a site-wide default. However, you could explicitly specify your @_site_level at the group level for every group to achieve the same effect. Once specified as a group attribute, the password applies to all pages in the group unless overridden, just like any other password. Identity-based authorization (username/password logins, AuthUser)Unlike many systems which have identity-based systems for controlling access to pages (e.g., using a separate username and password for each person), PmWiki defaults to a password-based system as described above. In general password-based systems are often easier to maintain because they avoid the administrative overheads of creating user accounts, recovering lost passwords, and mapping usernames to permitted actions. However, PmWiki's authuser.php script augments the password-based system to allow access to pages based on a username and password combination. See AuthUser for more details on controlling access to pages based on user identity. Security holes ...Administrators need to carefully plan where passwords are applied to avoid opening inadvertent security holes. If your wiki is open (anyone can read and edit), this would not seem to be a concern, except, a malicious or confused user could apply a read password to a group and make the group completely unavailable to all other users. At the very least, even an open wiki should have a site-wide "admin" password and a site-wide "attr" password set in config.php. The sample-config.php file distributed with PmWiki indicates that the PmWiki and Main groups have "attr" locked by default, but if anyone creates a new group, "attr" is unlocked. Administrators must remember to set "attr" passwords for each new group (if desired) in this case. An easier solution is to include these lines in config.php : $DefaultPasswords['admin'] = pmcrypt('youradminpassword'); $DefaultPasswords['attr'] = pmcrypt('yourattrpassword'); Encrypting passwords in config.phpOne drawback to using the pmcrypt() function directly to set passwords in config.php is that anyone able to view the file will see the unencrypted password. For example, if config.php contains $DefaultPasswords ['admin'] = pmcrypt('mysecret');
then the "mysecret" password is in plain text for others to see. However, a wiki administrator can obtain and use an encrypted form of the password directly by using $1$hMMhCdfT$mZSCh.BJOidMRn4SOUUSi1
The string returned from $DefaultPasswords ['admin'] = '$1$hMMhCdfT$mZSCh.BJOidMRn4SOUUSi1';
Note that in the encrypted form the pmcrypt function and parentheses are removed, since the password is already encrypted. Also, the encrypted password must be in single quotes. In this example the password is still " Please note that the encrypted password should be created with ?action=crypt on the wiki that will use it. A password encrypted on one system may or may not be usable on another. Removing passwordsTo remove a site password entirely, such as the default locked password for uploads, just set it to empty: $DefaultPasswords ['upload'] = '';
You can also use the special password "@nopass" via Revoking or invalidating passwordsIf a password is compromised and the wiki administrator wants to quickly invalidate all uses of that password on a site, a quick solution is the following in local/config.php: $ForbiddenPasswords = array('secret', 'tanstaafl'); if (in_array(@$_POST['authpw'], $ForbiddenPasswords)) unset($_POST['authpw']); This prevents "secret" and "tanstaafl" from ever being accepted as a valid authorization password, regardless of what pages may be using it. See Also
Protecting actions (example)Each action can be password protected. Cookbook authors providing scripts with own actions can use this also, but I'll limit the example to a (by default) not protected There are several solutions for that:
If you additionally want to set the password in the attributes page add:
In general, adding the prefix 'passwd' to an action name in the The full set of steps to add new password handling for an action such as "diff" would be: # add a new (encrypted) field to the attr page $PageAttributes['passwddiff'] = '$[Set new history password:]'; # clear the default password for 'diff' $DefaultPasswords['diff'] = ''; # Tell PmWiki that the 'diff' password allows action 'diff'. $HandleAuth['diff'] = 'diff'; # Tell PmWiki that a 'read' password # (or optionally the 'edit') password # is also sufficient to enable 'diff'. # Of course, the 'admin' password will work too. $AuthCascade['diff'] = 'read'; ## or 'edit' There seems to be a default password. What is it? There isn't any valid password until you set one. Passwords admin describes how to set one. PmWiki comes "out of the box" with How do I use passwd-formatted files (like .htpasswd) for authentication? See AuthUser, Cookbook:HtpasswdForm or Cookbook:UserAuth2. Is there anything I can enter in a GroupAttributes field to say 'same as the admin password'? If not, is there anything I can put into the config.php file to have the same effect? Enter '@lock' in GroupAttributes?action=attr to require an admin password for that group. How do I edit protect, say, all RecentChanges pages? How can I read password protect all pages in a group except the HomePage using configuration files? As described in PmWiki.GroupCustomizations per-group or per-page configuration files should not be used for defining passwords. The reason is that per-group (or per-page) customization files are only loaded for the current page. So, if
and because the GroupA.php file wasn't loaded (we're looking at Main.WikiSandbox --> local/Main.php), there's no read password set. How can I password protect the creation of new pages? See Cookbook:LimitWikiGroups, Cookbook:NewGroupWarning, Cookbook:LimitNewPagesInWikiGroups. How do I change the password prompt screen? If your question is about how to make changes to that page... edit Site.AuthForm. If your question is about how to change which page you are sent to when prompted for a password, you might check out the Cookbook:CustomAuthForm for help. How do I change the prompt on the attributes ( Simply create a new page at Site.AttrForm?, and add the following line of code to
Note that this only changes the text above the password inputs on the attributes page, but doesn't change the inputs themselves - the inputs have to be dealt with separately. See Cookbook:CustomAttrForm for more info. I get http error 500 "Internal Server Error" when I try to log in. What's wrong? This can happen if the encrypted passwords are not created on the web server that hosts the PmWiki. Solution: Create the passwords on the system with the oldest PHP version and use them on all other systems. I only want users to have to create an 'edit' password, which is automatically used for their 'upload' & 'attr' passwords (without them having to set those independently). How do I do this? By setting
< Notify | Documentation Index | Ref count > This page may have a more recent version on pmwiki.org: PmWiki:PasswordsAdmin, and a talk page: PmWiki:PasswordsAdmin-Talk. |
|
View Edit Attributes History Attach Print Search Page last modified on October 03, 2017, at 12:04 AM |