Passwords
Table of contents
PmWiki本身可設定密碼保謢。作者通常希望能夠將密碼應用於個人網頁或wiki群組?。 密碼由管理員設置，可以適用於單一的頁面，wiki群組?，或到 整個網站? 。如同任何訪問控制系統，密碼保護機制這裡只是描述一小部分的整體系統和wikisecurity?
作為一個作者編輯...
個人作者，一般可設置 3 種類型的密碼
- 進入頁面或wiki群組網頁，可使用
read(登入)密碼 - 編輯單一頁面或一小組網頁，可使用
edit(編輯)密碼 - 更改或設置密碼,用於保護單一的頁面或群組網頁，使用
attr(管理)密碼
保護單一頁面
?action=attr
可於訪問網頁中的URL (地址)後面輸入, 表單式頁面便出現，這時您可以設置 read , edit , attr 或修改密碼，
在表單中輸入的密碼為明文; PmWiki便會自動加密及儲存。
其他選項：
- 假如密碼格留空白,那一欄已設定的密碼紀錄不會被改變
- 要刪除密碼 (回到原本 網站的設定), 在表格中輸入
clear
- 為了可以編輯頁面，即使一組或網站已經設置密碼 ，輸入
@nopass
- 要鎖定某頁面，作個人密碼管理，請輸入
@lock
- To assign the site's site-wide passwords to the read, edit, or attr password for the page，請輸入
@_site_edit, @_site_read, @_site_admin or @_site_upload
保護wiki群組的網頁
要為 wiki群組? 設定密碼比較上複雜 -- 剛才設定的密碼special page?在每個組稱為
首先，你可以進入GroupAttributes屬性頁，通過輸入 URL（地址），如
http://example.com/pmwiki/pmwiki.php?n=GroupName.GroupAttributes?action=attr
代入 example.com以您的域名，及 GroupName 組別名稱
然後，進入表單式的頁面，您可以設置或清除 read, edit, 或 attr 密碼唯整個組別。
在表單中輸入的密碼為明文; PmWiki 為你自動加密。
其他選項:
- 要從一群組刪除密碼(回到原本 網站的設定), 在表格中輸入
- 為了可以編輯頁面，即使網站已經設置密碼 ，輸入
- 要鎖定某頁面，作個人密碼管理，請輸入
- (本文從版本 2.2.3) To assign the site's site-wide passwords to the read, edit, or attr password for the group，請輸入
@_site_edit, @_site_read, @_site_admin or @_site_upload
密碼
密碼可以包含任何字符的組合，除此之外.. 密碼越長，強度 最好.
多個密碼
同一頁面設多個密碼，群組或網站是允許的 只需輸入多個密碼用空格隔開。這使您有一個read密碼，一個同時允許read與edit的密碼 。換句話說，如果登入密碼為
和編輯密碼
然後輸入
設定新的讀取權限密碼: alpha beta 設定新的寫入權限密碼: beta
這說明表示
或
能夠訪問頁面, 但只有
能夠編輯。由於 PmWiki 分別檢查了登入和編輯密碼，因此輸入beta這個密碼同時擁有閱讀和編輯功能。
保護網站
密碼可以被應用到整個網站，維基 的 config.php. 見 passwords? 管理的細節。
administrator
作為一個網站管理員...
您可以嚴格按照上述的作者設置網頁和群組的密碼，您還可以：
- 設定整個網站的網頁和群組沒有密碼
- 用
attr密碼來控制誰可以設置密碼頁 - 用
upload密碼控制文件upload功能（如上傳啟用） - 用
admin密碼設置覆蓋任何個人或群組頁
欲了解更多管理員密碼咨詢，見 PasswordsAdmin?.
那個密碼權限最大?
在 PmWiki裡，單一頁面密碼覆蓋群組密碼，群組密碼覆蓋網站設定的 密碼，以及管理員密碼覆蓋所有的密碼。這給出了一個很大的彈性以控制訪問wiki頁面。
開放已被群組密碼保護的頁面
有時我們想 "解除" 群組或網站鎖定的單一個網頁 。在這種情況下，使用特殊密碼
是用來表示允許訪問的網頁，而無需輸入密碼。
例如，假設有一個 Main.GroupAttributes 群的編輯密碼設置，從而限制了的所有 Main.群組 進行編輯，這時，我們要為Main.WikiSandbox 編輯成沒有密碼，運用
為編輯 Main.WikiSandbox 成不需保護的頁面, 因為密碼已被Main.群組設置。我們便要編輯 Main.WikiSandbox 成為特殊頁面
它告訴 PmWiki忽略任何網站範圍或群組級限制該網頁。
How can I password protect all the pages and groups on my site? Do I really have to set passwords page by page, or group by group?
Administrators can set passwords for the entire site by editing the config.php file; they don't have to set passwords for each page or group. For example, to set the entire site to be editable only by those who know an "edit" password, an administrator can add a line like the following to local/config.php:
$DefaultPasswords['edit'] = crypt('edit_password');
For more information about the password options that are available only to administrators, see PasswordsAdmin?.
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.
The crypt function changed during the PHP development, e.g. a password encrypted with PHP 5.2 can not be decrypted in PHP 5.1, but PHP 5.2 can decrypt passwords created by PHP 5.1.
This situation normally happens if you prepare everything on your local machine with the latest PHP version and you upload the passwords to a webserver which is running an older version.
The same error occurs when you add encrypted passwords to local/config.php.
Solution: Create the passwords on the system with the oldest PHP version and use them on all other systems.
How can I create private groups for users, so that each user can edit pages in their group, but no one else (other than the admin) can?
Administrators can use the AuthUser recipe and add the following few lines to their local/config.php file to set this up:
$group = FmtPageName('$Group', $pagename); $DefaultPasswords['edit'] = 'id:'.$group;
include_once("$FarmD/scripts/authuser.php");
This automatically gives edit rights to a group to every user who has the same user name as the group name.
How come when I switch to another wiki within a farm, I keep my same authorization?
PmWiki uses PHP sessions to keep track of authentication/authorization information, and by default PHP sets things up such that all interactions with the same server are considered part of the same session.
An easy way to fix this is to make sure each wiki is using a different cookie name for its session identifier. Near the top of one of the wiki's local/config.php files, before calling authuser or any other recipes, add a line like:
session_name('XYZSESSID');
You can pick any alphanumeric name for XYZSESSID; for example, for the cs559-1 wiki you might choose
session_name('CS559SESSID');
This will keep the two wikis' sessions independent of each other.