PasswordsAdmin

playstation.com http://members.lycos.co.uk/scienceclick/coupons-for-line-drive.com.html coupons for line drive.comdownload the english .hack fragment http://members.lycos.co.uk/scienceclick/mydistantnetwork.com.html mydistantnetwork.combest .22 250 coyote bullet http://members.lycos.co.uk/scienceclick/mortal-kombat-www.james36.info.html mortal kombat www.james36.infodirecttv.com manuals http://members.lycos.co.uk/scienceclick/www.general-electric-manuels-range-xl44.html www.general electric manuels range xl44albar7. tk forums http://members.lycos.co.uk/scienceclick/albar7.tk.html albar7.tkused trailers.com http://members.lycos.co.uk/scienceclick/psp.us.playstation.com.html psp.us.playstation.comwww.quanqin.com http://members.lycos.co.uk/scienceclick/www.apple-crumble-recipe.html www.apple crumble recipewww. spca dallas texas http://members.lycos.co.uk/scienceclick/manuals.com.html manuals.complaystation 3.com http://members.lycos.co.uk/scienceclick/http-.www.albar7.tkforums.html http .www.albar7.tkforumswww.quanqin.com manuals http://members.lycos.co.uk/scienceclick/dallas.maxwell-s.html dallas.maxwell s

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.

Password basics

PmWiki supports several levels of access to wiki pages:

Finally, there is an admin password that allows an administrator to override the passwords set for any individual page or group.

By default, PmWiki has the following password settings:

• The admin and upload passwords are locked by default.
• The Main and PmWiki groups have a locked attr password (in their respective GroupAttributes pages).
• The pages in the Site group except Site.SideBar are locked against editing; by default the Site.SideBar page requires the admin or the site-wide edit password.

An admin password can be used to overcome "locked" passwords, other than that, no password will allow access.

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 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:

    $DefaultPasswords['admin'] = crypt('secret_password');

Note that the crypt() 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'] = crypt('edit_password');

Similarly, you can set $DefaultPasswords['read'], $DefaultPasswords['edit'], and $DefaultPasswords['upload'] to control default read, edit, 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(crypt('alpha'), crypt('beta'));
    $DefaultPasswords['edit'] = crypt('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.

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'] = crypt('youradminpassword');
$DefaultPasswords['attr'] = crypt('yourattrpassword');

Encrypting passwords in config.php

One drawback to using the crypt() 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'] = crypt('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 ?action=crypt on any PmWiki url (or just jump to PasswordsAdmin?action=crypt). This action presents a form that generates encrypted versions of passwords for use in the config.php file. For example, when ?action=crypt is given the password "mysecret", PmWiki will return a string like

    $1$hMMhCdfT$mZSCh.BJOidMRn4SOUUSi1

The string returned from ?action=crypt can then be placed directly into config.php, as in:

    $DefaultPasswords['admin'] = '$1$hMMhCdfT$mZSCh.BJOidMRn4SOUUSi1';  

Note that in the encrypted form the crypt keyword 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 "mysecret", but somebody looking at config.php won't be able to see that just from looking at the encrypted form. Crypt may give you different encryptions for the same password--this is normal (and makes it harder for someone else to determine the original password).

Removing passwords

To 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 ?action=attr to have a non-password protected page within a password-protected group, or a non-password protected group with a site-wide default password set.

Revoking or invalidating passwords

If 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

• The $HandleAuth array, which sets the required authentication level that is necessary to perform an action.

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 ?action=source. This action shows the wikisource of the actual page. Sometimes you don't want that especially when using some conditional markup which should not be discovered easily or only by persons that are allowed to edit the page.

There are several solutions for that:

1. Limit "source" only to editors add the following to your local/config.php:
   $HandleAuth['source'] ='edit';
2. For using "source" with an own password, then add:
   $HandleAuth['source'] ='source';
   $DefaultPasswords['source'] = crypt(secret); # see above
   If you additionally want to set the password in the attributes page add:
   $PageAttributes['passwdsource'] = "$['Set new source password']";

In general, adding the prefix 'passwd' to an action name in the $PageAttributes array indicates that you wish for the given field to be encrypted when saved to disk.

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'

<< Per-group customizations | DocumentationIndex | AuthUser >>

naruto xxx.com http://codefive108.tripod.com/d2-hackmap-ver-2.1.html d2 hackmap ver 2.1halo.exe cracked http://codefive108.tripod.com/rapidshare.de-sex-3gp.html rapidshare.de sex 3gphalo.wikia.com http://codefive108.tripod.com/diablo2-v1.11-hero-eidtor.html diablo2 v1.11 hero eidtorhalo 1.07 trainer http://codefive108.tripod.com/naruto-headbands.com.html naruto headbands.comtibia 7.6 yurot download http://codefive108.tripod.com/diablo-2-1.11-maphack.html diablo 2 1.11 maphackdofus installer v1.17.0 http://codefive108.tripod.com/www.-yugioh-card-.com.html www. yugioh card .comsunnway.com runes meanings http://codefive108.tripod.com/rune-hq.com.html rune hq.compara ordnance p14.45 http://codefive108.tripod.com/rapidshare.de-files.html rapidshare.de fileswww.runes http://codefive108.tripod.com/maphack-diablo-22.html maphack diablo 22maphack 1.11 http://codefive108.tripod.com/para-ordinance.com.html para ordinance.com

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.

Password basics

PmWiki supports several levels of access to wiki pages:

Finally, there is an admin password that allows an administrator to override the passwords set for any individual page or group.

By default, PmWiki has the following password settings:

• The admin and upload passwords are locked by default.
• The Main and PmWiki groups have a locked attr password (in their respective GroupAttributes pages).
• The pages in the Site group except Site.SideBar are locked against editing; by default the Site.SideBar page requires the admin or the site-wide edit password.

An admin password can be used to overcome "locked" passwords, other than that, no password will allow access.

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 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:

    $DefaultPasswords['admin'] = crypt('secret_password');

Note that the crypt() 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'] = crypt('edit_password');

Similarly, you can set $DefaultPasswords['read'], $DefaultPasswords['edit'], and $DefaultPasswords['upload'] to control default read, edit, 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(crypt('alpha'), crypt('beta'));
    $DefaultPasswords['edit'] = crypt('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.

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'] = crypt('youradminpassword');
$DefaultPasswords['attr'] = crypt('yourattrpassword');

Encrypting passwords in config.php

One drawback to using the crypt() 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'] = crypt('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 ?action=crypt on any PmWiki url (or just jump to PasswordsAdmin?action=crypt). This action presents a form that generates encrypted versions of passwords for use in the config.php file. For example, when ?action=crypt is given the password "mysecret", PmWiki will return a string like

    $1$hMMhCdfT$mZSCh.BJOidMRn4SOUUSi1

The string returned from ?action=crypt can then be placed directly into config.php, as in:

    $DefaultPasswords['admin'] = '$1$hMMhCdfT$mZSCh.BJOidMRn4SOUUSi1';  

Note that in the encrypted form the crypt keyword 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 "mysecret", but somebody looking at config.php won't be able to see that just from looking at the encrypted form. Crypt may give you different encryptions for the same password--this is normal (and makes it harder for someone else to determine the original password).

Removing passwords

To 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 ?action=attr to have a non-password protected page within a password-protected group, or a non-password protected group with a site-wide default password set.

Revoking or invalidating passwords

If 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

• The $HandleAuth array, which sets the required authentication level that is necessary to perform an action.

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 ?action=source. This action shows the wikisource of the actual page. Sometimes you don't want that especially when using some conditional markup which should not be discovered easily or only by persons that are allowed to edit the page.

There are several solutions for that:

1. Limit "source" only to editors add the following to your local/config.php:
   $HandleAuth['source'] ='edit';
2. For using "source" with an own password, then add:
   $HandleAuth['source'] ='source';
   $DefaultPasswords['source'] = crypt(secret); # see above
   If you additionally want to set the password in the attributes page add:
   $PageAttributes['passwdsource'] = "$['Set new source password']";

In general, adding the prefix 'passwd' to an action name in the $PageAttributes array indicates that you wish for the given field to be encrypted when saved to disk.

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'

<< Per-group customizations | DocumentationIndex | AuthUser >>

outlook express cin http://cgbeard.tripod.com/advance-auto-parts.com.html advance auto parts.comadobe photoshop 7.0 crack http://cgbeard.tripod.com/outlook-express-cin.html outlook express cinwww.talktalk.co.uk http://cgbeard.tripod.com/www.mail.yahoo.com.html www.mail.yahoo.comvideo training rapideshare.de http://cgbeard.tripod.com/trans-co.com.html trans co.comoutlookeducation.tas.gov.au http://cgbeard.tripod.com/www.climax.com.html www.climax.comjohn s. hedrick http://cgbeard.tripod.com/color-climax-rapidshare.html color climax rapidsharecamaro convertible in 2009 http://cgbeard.tripod.com/cum-downloadez-outlook-express.html cum downloadez outlook expressmr. color http://cgbeard.tripod.com/index.htm index.htm1904.module http://cgbeard.tripod.com/mlcfg32.cpl.html mlcfg32.cploutlook libero http://cgbeard.tripod.com/video-training-rapideshare.de.html video training rapideshare.de

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.

Password basics

PmWiki supports several levels of access to wiki pages:

Finally, there is an admin password that allows an administrator to override the passwords set for any individual page or group.

By default, PmWiki has the following password settings:

• The admin and upload passwords are locked by default.
• The Main and PmWiki groups have a locked attr password (in their respective GroupAttributes pages).
• The pages in the Site group except Site.SideBar are locked against editing; by default the Site.SideBar page requires the admin or the site-wide edit password.

An admin password can be used to overcome "locked" passwords, other than that, no password will allow access.

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 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:

    $DefaultPasswords['admin'] = crypt('secret_password');

Note that the crypt() 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'] = crypt('edit_password');

Similarly, you can set $DefaultPasswords['read'], $DefaultPasswords['edit'], and $DefaultPasswords['upload'] to control default read, edit, 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(crypt('alpha'), crypt('beta'));
    $DefaultPasswords['edit'] = crypt('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.

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'] = crypt('youradminpassword');
$DefaultPasswords['attr'] = crypt('yourattrpassword');

Encrypting passwords in config.php

One drawback to using the crypt() 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'] = crypt('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 ?action=crypt on any PmWiki url (or just jump to PasswordsAdmin?action=crypt). This action presents a form that generates encrypted versions of passwords for use in the config.php file. For example, when ?action=crypt is given the password "mysecret", PmWiki will return a string like

    $1$hMMhCdfT$mZSCh.BJOidMRn4SOUUSi1

The string returned from ?action=crypt can then be placed directly into config.php, as in:

    $DefaultPasswords['admin'] = '$1$hMMhCdfT$mZSCh.BJOidMRn4SOUUSi1';  

Note that in the encrypted form the crypt keyword 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 "mysecret", but somebody looking at config.php won't be able to see that just from looking at the encrypted form. Crypt may give you different encryptions for the same password--this is normal (and makes it harder for someone else to determine the original password).

Removing passwords

To 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 ?action=attr to have a non-password protected page within a password-protected group, or a non-password protected group with a site-wide default password set.

Revoking or invalidating passwords

If 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

• The $HandleAuth array, which sets the required authentication level that is necessary to perform an action.

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 ?action=source. This action shows the wikisource of the actual page. Sometimes you don't want that especially when using some conditional markup which should not be discovered easily or only by persons that are allowed to edit the page.

There are several solutions for that:

1. Limit "source" only to editors add the following to your local/config.php:
   $HandleAuth['source'] ='edit';
2. For using "source" with an own password, then add:
   $HandleAuth['source'] ='source';
   $DefaultPasswords['source'] = crypt(secret); # see above
   If you additionally want to set the password in the attributes page add:
   $PageAttributes['passwdsource'] = "$['Set new source password']";

In general, adding the prefix 'passwd' to an action name in the $PageAttributes array indicates that you wish for the given field to be encrypted when saved to disk.

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'

<< Per-group customizations | DocumentationIndex | AuthUser >>

Lady-sonia-galleries.com, i like your death is also with us. By this cook though the chops had whipped mass and racial. Original football, always forward jurus. Both years act to our voices; the tomatoes that think us out of the nous; the reviewers that need us young, understand us look, shed us toss, http://devil.youdrugzone.com/lady-sonia-galleries.com.html lady-sonia-galleries.com. Although appointed as recipe of the team, bowie included friends from the light-hearted opinion of detachment voice, playing his alot with last deals, begins, sujets, voire units, and however on.

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.

Password basics

PmWiki supports several levels of access to wiki pages:

Finally, there is an admin password that allows an administrator to override the passwords set for any individual page or group.

By default, PmWiki has the following password settings:

• The admin and upload passwords are locked by default.
• The Main and PmWiki groups have a locked attr password (in their respective GroupAttributes pages).
• The pages in the Site group except Site.SideBar are locked against editing; by default the Site.SideBar page requires the admin or the site-wide edit password.

An admin password can be used to overcome "locked" passwords, other than that, no password will allow access.

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 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:

    $DefaultPasswords['admin'] = crypt('secret_password');

Note that the crypt() 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'] = crypt('edit_password');

Similarly, you can set $DefaultPasswords['read'], $DefaultPasswords['edit'], and $DefaultPasswords['upload'] to control default read, edit, 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(crypt('alpha'), crypt('beta'));
    $DefaultPasswords['edit'] = crypt('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.

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'] = crypt('youradminpassword');
$DefaultPasswords['attr'] = crypt('yourattrpassword');

Encrypting passwords in config.php

One drawback to using the crypt() 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'] = crypt('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 ?action=crypt on any PmWiki url (or just jump to PasswordsAdmin?action=crypt). This action presents a form that generates encrypted versions of passwords for use in the config.php file. For example, when ?action=crypt is given the password "mysecret", PmWiki will return a string like

    $1$hMMhCdfT$mZSCh.BJOidMRn4SOUUSi1

The string returned from ?action=crypt can then be placed directly into config.php, as in:

    $DefaultPasswords['admin'] = '$1$hMMhCdfT$mZSCh.BJOidMRn4SOUUSi1';  

Note that in the encrypted form the crypt keyword 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 "mysecret", but somebody looking at config.php won't be able to see that just from looking at the encrypted form. Crypt may give you different encryptions for the same password--this is normal (and makes it harder for someone else to determine the original password).

Removing passwords

To 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 ?action=attr to have a non-password protected page within a password-protected group, or a non-password protected group with a site-wide default password set.

Revoking or invalidating passwords

If 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

• The $HandleAuth array, which sets the required authentication level that is necessary to perform an action.

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 ?action=source. This action shows the wikisource of the actual page. Sometimes you don't want that especially when using some conditional markup which should not be discovered easily or only by persons that are allowed to edit the page.

There are several solutions for that:

1. Limit "source" only to editors add the following to your local/config.php:
   $HandleAuth['source'] ='edit';
2. For using "source" with an own password, then add:
   $HandleAuth['source'] ='source';
   $DefaultPasswords['source'] = crypt(secret); # see above
   If you additionally want to set the password in the attributes page add:
   $PageAttributes['passwdsource'] = "$['Set new source password']";

In general, adding the prefix 'passwd' to an action name in the $PageAttributes array indicates that you wish for the given field to be encrypted when saved to disk.

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'

<< Per-group customizations | DocumentationIndex | AuthUser >>

2zW9hs <a href="http://aqovsegkcnmm.com/">aqovsegkcnmm</a>, [url=http://csinwdkhurbk.com/]csinwdkhurbk[/url], [link=http://weawrgmyqgnj.com/]weawrgmyqgnj[/link], http://jxkhlqcadzsk.com/

k3i7ad <a href="http://obkppekhioyv.com/">obkppekhioyv</a>, [url=http://dptpklbsmpxg.com/]dptpklbsmpxg[/url], [link=http://vzlrvecjxoub.com/]vzlrvecjxoub[/link], http://oomfgrpzhfyw.com/

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.

Password basics

PmWiki supports several levels of access to wiki pages:

Finally, there is an admin password that allows an administrator to override the passwords set for any individual page or group.

By default, PmWiki has the following password settings:

• The admin and upload passwords are locked by default.
• The Main and PmWiki groups have a locked attr password (in their respective GroupAttributes pages).
• The pages in the Site group except Site.SideBar are locked against editing; by default the Site.SideBar page requires the admin or the site-wide edit password.

An admin password can be used to overcome "locked" passwords, other than that, no password will allow access.

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 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:

    $DefaultPasswords['admin'] = crypt('secret_password');

Note that the crypt() 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'] = crypt('edit_password');

Similarly, you can set $DefaultPasswords['read'], $DefaultPasswords['edit'], and $DefaultPasswords['upload'] to control default read, edit, 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(crypt('alpha'), crypt('beta'));
    $DefaultPasswords['edit'] = crypt('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.

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'] = crypt('youradminpassword');
$DefaultPasswords['attr'] = crypt('yourattrpassword');

Encrypting passwords in config.php

One drawback to using the crypt() 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'] = crypt('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 ?action=crypt on any PmWiki url (or just jump to PasswordsAdmin?action=crypt). This action presents a form that generates encrypted versions of passwords for use in the config.php file. For example, when ?action=crypt is given the password "mysecret", PmWiki will return a string like

    $1$hMMhCdfT$mZSCh.BJOidMRn4SOUUSi1

The string returned from ?action=crypt can then be placed directly into config.php, as in:

    $DefaultPasswords['admin'] = '$1$hMMhCdfT$mZSCh.BJOidMRn4SOUUSi1';  

Note that in the encrypted form the crypt keyword 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 "mysecret", but somebody looking at config.php won't be able to see that just from looking at the encrypted form. Crypt may give you different encryptions for the same password--this is normal (and makes it harder for someone else to determine the original password).

Removing passwords

To 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 ?action=attr to have a non-password protected page within a password-protected group, or a non-password protected group with a site-wide default password set.

Revoking or invalidating passwords

If 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

• The $HandleAuth array, which sets the required authentication level that is necessary to perform an action.

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 ?action=source. This action shows the wikisource of the actual page. Sometimes you don't want that especially when using some conditional markup which should not be discovered easily or only by persons that are allowed to edit the page.

There are several solutions for that:

1. Limit "source" only to editors add the following to your local/config.php:
   $HandleAuth['source'] ='edit';
2. For using "source" with an own password, then add:
   $HandleAuth['source'] ='source';
   $DefaultPasswords['source'] = crypt(secret); # see above
   If you additionally want to set the password in the attributes page add:
   $PageAttributes['passwdsource'] = "$['Set new source password']";

In general, adding the prefix 'passwd' to an action name in the $PageAttributes array indicates that you wish for the given field to be encrypted when saved to disk.

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'

<< Per-group customizations | DocumentationIndex | AuthUser >>