From: Reini U. <ru...@us...> - 2004-03-25 23:48:24
|
Update of /cvsroot/phpwiki/phpwiki/doc In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv5984 Modified Files: README.phpwiki-auth Log Message: linebreaks + cookie notes Index: README.phpwiki-auth =================================================================== RCS file: /cvsroot/phpwiki/phpwiki/doc/README.phpwiki-auth,v retrieving revision 1.4 retrieving revision 1.5 diff -u -2 -b -p -d -r1.4 -r1.5 --- README.phpwiki-auth 10 Mar 2004 15:41:27 -0000 1.4 +++ README.phpwiki-auth 25 Mar 2004 23:37:30 -0000 1.5 @@ -38,7 +38,9 @@ username-password pairs (AuthMethods) an Temporarily: -; ENABLE_USER_NEW : This will be removed with the 1.3.8 release. It's just to decide if ~WikiUserNew.php should be loaded instead of the old ~WikiUser.php +; ENABLE_USER_NEW : This will be removed with the 1.3.9 release. +;: It's just to decide if ~WikiUserNew.php should be loaded instead of the old ~WikiUser.php ! ALLOW_ANON_USER + To establish a COMPLETELY private wiki, such as an internal corporate one set ALLOW_ANON_USER = false, and probably require user passwords as described below. @@ -47,23 +49,39 @@ any page. This is similar to HttpAuth. ! ALLOW_ANON_EDIT -This feature was called REQUIRE_SIGNIN_BEFORE_EDIT before. To enable ALLOW_BOGO_LOGIN and/or ALLOW_USER_PASSWORDS, ALLOW_ANON_EDIT must be false, otherwise it will override ALLOW_BOGO_LOGIN and ALLOW_USER_PASSWORDS. This will go away, with true page permissions. + +This feature was called REQUIRE_SIGNIN_BEFORE_EDIT before. To enable +ALLOW_BOGO_LOGIN and/or ALLOW_USER_PASSWORDS, ALLOW_ANON_EDIT must be +false, otherwise it will override ALLOW_BOGO_LOGIN and +ALLOW_USER_PASSWORDS. This will go away, with true page permissions. ! ALLOW_BOGO_LOGIN -If ALLOW_BOGO_LOGIN is true, users are allowed to login (with any/no password) using any userid which: + +If ALLOW_BOGO_LOGIN is true, users are allowed to login (with +any/no password) using any userid which: 1) is not the ADMIN_USER, and 2) is a valid WikiWord (matches $WikiNameRegexp.) -If true, users may be created by themselves. Otherwise we need seperate ALLOW_USER_PASSWORDS auth. -If such a user will create a so called HomePage named after his WikiWord userid, he will be able to store his preferences and password there. -If ALLOW_ANON_EDIT = true, one may still sign in to be able to store UserPreferences and named RecentChanges entries. + +If true, users may be created by themselves. Otherwise we need +seperate ALLOW_USER_PASSWORDS auth. If such a user will create a so +called HomePage named after his WikiWord userid, he will be able to +store his preferences and password there. +If ALLOW_ANON_EDIT = true, one may still sign in to be able to store +UserPreferences and named RecentChanges entries. PASSWORD_LENGTH_MINIMUM is ignored by bogo login attempts. If an empty password is used, any user can sign in with this userid. ! REQUIRE_SIGNIN_BEFORE_EDIT (Legacy) + If set, then if an anonymous user attempts to edit a page he will be required to sign in. This constant was replaced by ALLOW_ANON_EDIT in v1.3.8. -If ALLOW_BOGO_LOGIN is true, of course, no password is required, but the user must still sign in under some sort of WikiWord name. This will go away, with true page permissions. +If ALLOW_BOGO_LOGIN is true, of course, no password is required, but the user +must still sign in under some sort of WikiWord name. This will go away, +with true page permissions. ! ALLOW_USER_PASSWORDS -True User Authentification is used with Bogo Login and not-empty passwords or ALLOW_USER_PASSWORDS = true. + +True User Authentification is used with Bogo Login and not-empty +passwords or ALLOW_USER_PASSWORDS = true. + To require user passwords set <verbatim> @@ -72,17 +90,33 @@ To require user passwords set ALLOW_USER_PASSWORDS = true </verbatim> -Otherwise any anon or bogo user might login without any or a wrong password. A login attempt with ALLOW_USER_PASSWORDS = true depends on the defined USER_AUTH_ORDER auth methods, the USER_AUTH_POLICY and PASSWORD_LENGTH_MINIMUM. +Otherwise any anon or bogo user might login without any or a wrong +password. A login attempt with ALLOW_USER_PASSWORDS = true depends on +the defined USER_AUTH_ORDER auth methods, the USER_AUTH_POLICY and +PASSWORD_LENGTH_MINIMUM. !! FAQ - UPGRADE PROBLEMS: -* ''Fatal error: The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition wikiuser of the object you are trying to operate on was loaded _before_ the session was started in...'' +* ''Fatal error: The script tried to execute a method or access a + property of an incomplete object. Please ensure that the class + definition wikiuser of the object you are trying to operate on was + loaded _before_ the session was started in...'' -This error will appear you switch from old (or from new to old) in the same browser session. You have an old (or new) WikiUser object in your current session, which is incompatible with the new (or old) WikiUser object on session restauration. -Workaround: Close and open your browser again. The session cookie should be destroyed, and you will get a fresh new WikiUser object. Your default WIKI_ID (your username) will not be lost. +This error will appear you switch from old (or from new to old) in the +same browser session. You have an old (or new) WikiUser object in your +current session, which is incompatible with the new (or old) WikiUser +object on session restauration. + +Workaround: Close and open your browser again. The session cookie +should be destroyed, and you will get a fresh new WikiUser +object. Your default WIKI_ID (your username) will not be lost. * ''lib\Template.php:22: Warning[2]: fopen("", "rb") - No such file or directory'' -PHPWIKI_DIR could not be determined automatically. You probably started from a different diretory. -Workaround: Set PHPWIKI_DIR in index.php or in your start script. You most likely have to set DATA_PATH also, when your pages look like the ancient-style Wiki (Times-Roman, black-white), i.e. no CSS is loaded. +PHPWIKI_DIR could not be determined automatically. You probably +started from a different diretory. + +Workaround: Set PHPWIKI_DIR in index.php or in your start script. You +most likely have to set DATA_PATH also, when your pages look like the +ancient-style Wiki (Times-Roman, black-white), i.e. no CSS is loaded. @@ -91,12 +125,18 @@ Below we define which methods exists and !! USER_AUTH_ORDER auth methods -$USER_AUTH_ORDER is an array of the following strings. You can en-/disable any and change the order. +$USER_AUTH_ORDER is an array of the following strings. You can +en-/disable any and change the order. -* __~BogoLogin__: This will eventually replace the old ALLOW_BOGO_LOGIN constant, but it will require PASSWORD_LENGTH_MINIMUM. So non-empty passwords can be disabled. +* __~BogoLogin__: This will eventually replace the old ALLOW_BOGO_LOGIN constant, + but it will require PASSWORD_LENGTH_MINIMUM. So non-empty passwords can be disabled. * __~PersonalPage__: Store passwords in the users homepage metadata (simple) -* __Db__: Use $DBAuthParams~[~] (see below) with PearDB or ADODB only. If 'auth_dsn' is undefined, and wiki pages are stored via SQL or ADODB, it uses the same database. (fastest) +* __Db__: Use $DBAuthParams~[~] (see below) with PearDB or ADODB only. + If 'auth_dsn' is undefined, and wiki pages are stored via SQL or ADODB, + it uses the same database. (fastest) * __LDAP__: Authenticate against LDAP_AUTH_HOST with the LDAP_AUTH_SEARCH settings * __IMAP__: Authenticate against IMAP_AUTH_HOST (e.g. an existing email account) -* __File__: Check username:crypted-passwords in .htaccess like files. Use Apache's htpasswd program to manage this file. +* __POP3__: Authenticate against POP3_AUTH_HOST (e.g. an existing email account) +* __File__: Check username:crypted-passwords in .htaccess like files. + Use e.g. Apache's htpasswd program to manage this file. * __~HttpAuth__: Use the protection by the webserver, either .htaccess or httpd.conf If no HTTP AUTH is enforced by the webserver (e.g no require valid-user), then @@ -104,9 +144,14 @@ $USER_AUTH_ORDER is an array of the foll entry dialog. -Each method is a WikiUser (in fact a ~_PassUser) class, which defines the checkPass() and userExists() methods and optionally mayChangePass() and storePass(). +Each method is a WikiUser (in fact a ~_PassUser) class, which defines the checkPass() and +userExists() methods and optionally mayChangePass() and storePass(). !! USER_AUTH_POLICY -The available policies defines how and when each auth method from USER_AUTH_ORDER is tried, and what to do on failure. Some policies require to know it at advance at initialization time, some have to check if a valid user exists and some simply check valid username - password pairs. +The available policies defines how and when each auth method from +USER_AUTH_ORDER is tried, and what to do on failure. Some policies +require to know it at advance at initialization time, some have to +check if a valid user exists and some simply check valid username - +password pairs. ;__old__: This policy checks all default USER_AUTH_ORDER methods, disables all not defined services (ldap, imap) and tries to use all available methods as in the previous PhpWiki releases with the stacked policy (slow). @@ -120,13 +165,17 @@ The available policies defines how and w ! $DBAuthParams~[~] + Statements for seperate DB User Authentication. -This array defines the database prepare statements to select and update the password and preferences. -This is typically used to interface with other applications or user databases in quasi secure wiki's. -(often so called "Content Management Systems"). -The database can be external like radius, phpnuke, courier authmysql, apache auth_mysql or just a simple -user table within phpwiki. -The most likely auth_dsn option is the same dsn as the wikipages, in fact if it's empty $DBParams~['dsn'~] is used. -If $DBParams~['db_type'~] is not ADODB, the Pear DB library is used (db_type = SQL). +This array defines the database prepare statements to select and +update the password and preferences. This is typically used to +interface with other applications or user databases in quasi secure +wiki's. (often so called "Content Management Systems"). +The database can be external like radius, phpnuke, courier authmysql, +apache auth_mysql or just a simple user table within phpwiki. +The most likely auth_dsn option is the same dsn as the wikipages, in +fact if it's empty $DBParams~['dsn'~] is used. If +$DBParams~['db_type'~] is not ADODB, the Pear DB library is used +(db_type = SQL). This is the list of the available options and some examples. For the statements we use the following symbolic variables: @@ -135,6 +184,9 @@ This is the list of the available option $pref_blob : serialized string of the PHP preferences array (may get large, but not too large. 128 - 1024. mysql TEXT is enough) $groupname : groupname + Note: The symbolic variables (like "$password", ...) must be enclosed in double quotes! -ADODB Note: With ADODB we must define the correct alias names: SELECT db_column as name +ADODB Warning: With ADODB we must currently define the correct alias names: SELECT db_column as name +This requirement will go away when we switch to FETCH_ROW instead of the slower FETCH_ASSOC +(scheduled for 1.4.0) ;auth_dsn: 'mysql://user@password:localhost/phpwiki' @@ -160,21 +212,35 @@ auth_user_exists is only needed with aut ;user_create: 'INSERT INTO user SET username="$userid", password="$password", pref="$pref_blob"' -If auth_update is not defined but auth_check is defined, the user cannot change his password. But then better crypt methods may be used also. $password is processed by the auth_crypt_method. -For mysql md5-crypt use auth_crypt_method = plain and 'UPDATE user SET password=PASSWORD("$password") WHERE username="$userid"' +If auth_update is not defined but auth_check is defined, the user +cannot change his password. But then better crypt methods may be used +also. $password is processed by the auth_crypt_method. +For mysql md5-crypt use auth_crypt_method = plain and 'UPDATE user SET +password=PASSWORD("$password") WHERE username="$userid"' -user_create is typically undefined, but may be defined to get rid of PersonalPage users completely. +user_create is typically undefined, but may be defined to get rid of +PersonalPage users completely. -auth_user_exists is only needed with auth_crypt_method = plain and USER_AUTH_POLICY = stacked or old or for certain plugins which want to list all users. With auth_crypt_method = crypt the auth_check statement is used for the userExists() check. +auth_user_exists is only needed with auth_crypt_method = plain and +USER_AUTH_POLICY = stacked or old or for certain plugins which want to +list all users. With auth_crypt_method = crypt the auth_check +statement is used for the userExists() check. USER => PREFERENCES -This can be optionally defined in an external DB. The default is the users homepage. +This can be optionally defined in an external DB. The default is the +users homepage. ;pref_select: 'SELECT pref as pref FROM user WHERE username="$userid"', -;pref_update: 'UPDATE user SET pref="$pref_blob" WHERE username="$userid"', +;pref_update: 'UPDATE user SET pref="$pref_blob" WHERE username="$userid"', or + mysql-specific: 'REPLACE INTO user SET prefs="$pref_blob", userid="$userid"' + (only if the pref table uses these two fields only!) + USERS <=> GROUPS -DB methods for lib/WikiGroup.php. This can be optionally defined in a file (see AUTH_GROUP_FILE) or an external DB. The default storage location is a special locked wikipage named after the group and as content a list of all groupmembers. +DB methods for lib/WikiGroup.php. This can be optionally defined in a +file (see AUTH_GROUP_FILE) or an external DB. The default storage +location is a special locked wikipage named after the group and as +content a list of all groupmembers. ;is_member: 'SELECT 1 FROM groups WHERE user=$userid"" AND group="$groupname"', @@ -186,18 +252,29 @@ DB methods for lib/WikiGroup.php. This c !! UserPreferences -The preferences are stored as serialized hash of non-default values, at the following locations: +The preferences are stored as serialized hash of non-default values, +at the following locations: -# Cookie +# Session (volatile) +# Cookie (only the userid as WIKI_ID) # PersonalPage # Database -~AnonUser uses Cookie alone. For signed in users (~BogoUser and higher) the PersonalPage and/or Database methods -are tried. If these methods fail (no such page or user exists) the Cookie method will be used. -For some short time a serialized array of _UserPreference objects was stored which was "not a good thing". +~AnonUser uses Cookie alone. For signed in users (~BogoUser and +higher) the PersonalPage and/or Database methods are tried. If these +methods fail (no such page or user exists) only the userid will be +stored in a Cookie. For some short time a serialized array of +_UserPreference objects was stored which was "not a good thing". There is code to detect these objects and convert them automatically. +Also serialized arrays stored in a WIKI_PREFS2 or WIKI_NAME cookie are +deprecated and are automatically converted and deleted. -To use the "PersonalPage" location a page with the same name as the userid must exist, the so called "HomePage". This does not need be a WikiWord pagename but it sure helps. +To use the "PersonalPage" location a page with the same name as the +userid must exist, the so called "HomePage". This does not need be a +WikiWord pagename but it sure helps. -If $DBAuthParams~['pref_select'~] is defined, PersonalPage preferences are ignored and the preferences are read from the database. If $DBAuthParams~['pref_update'~] is defined, the preferences are stored back into the database. +If $DBAuthParams~['pref_select'~] is defined, PersonalPage preferences +are ignored and the preferences are read from the database. If +$DBAuthParams~['pref_update'~] is defined, the preferences are stored +back into the database. !! Groups @@ -208,6 +285,6 @@ Group membership information can be stor # file -For the group wikipage you have to create for every group a page with a list of users and the -master group page called "CategoryGroup". +For the group wikipage you have to create for every group a page with +a list of users and the master group page called "CategoryGroup". For the database setup you can define the following $DBAuthParams[] statements. |