|
Cookbook /
UserAuthSummary: User-based authorization
Version: 0.70, 25 January 2006
Prerequisites: Last tested on PmWiki version: pmwiki-2.0.beta36; pmwiki-2.0.beta51 needs userauth-0.63 (0.62 incompatibility with basicauth)
Status: Obsolete
Maintainer:
GoalTo create greater access control for PmWiki installations where the admin does not want the whole world able to change pages or wishes to only allow select users to have editing access. Files
Userauth provides: cookbook/userauth.php
cookbook/userauth-pwchange.php
cookbook/userauth-admintool.php
cookbook/userauth/HtPasswd.php
cookbook/userauth/UserSessionVars.php
DescriptionThis PmWiki plugin makes it possible to restrict access to the entire wiki by requiring a username and password for certain actions. Individual pages and groups can still be password restricted in the same way that PmWiki does by default. However, user authentication happens before wiki password authentication. Additionally, the username doubles as the author name. The UserAuth package also contains two optional scripts that add functionality. One of the scripts, userauth-pwchange.php adds the ability for users to change their own passwords. Another script, userauth-admintool.php adds the ability for the admin user to edit user abilities and passwords as well as add new users. Please see the details within the scripts on how to install and configure them. By default this plugin reads username, password and ability information from a .htpasswd file. This file is created when the script is first run in the PmWiki "local" directory with the default restrictions that non authorized users can only read pages. The htpasswd file has an additional third field where abilities are stored. This field should not interfere if you wish to use the same htpassword file with Apache basic authentication. A typical htpassword file would look like the following: GuestUser::read,rss
LoggedInUser::pwchange
FredFlintstone:HWxwafxAweaXefafdae:read_all,edit_all
BarneyRubble:AsafasfAfadfadfad:read_group-PrivateArea,edit_group-PrivateArea,edit
WilmaFlintstone:GFSDGfgdfgsdfgdf:edit,upload
Admin:XwasgeGGGaaceexeadeE:admin
Version 0.70 adds a column to the htpassword file to store a full user name or description. htpassword files of the old format are automatically converted How would I allow edit access to Main.WikiSandbox? edit_page-WikiSanbox, edit_page-Main/WikiSanbox, edit_page-Main.WikiSanbox, edit_group-Main and edit_page-WikiSanbox? The abilities field is a list of actions the user can perform separated by commas. Abilities correspond to the same type of actions defined by PmWiki in the $DefaultPassword array as well as some custom actions: PmWiki Actions:
UserAuth Actions:
UserAuth User Groups:
Installation
require_once("cookbook/userauth.php");
(:loginform:)
Main.LoginPage is just the default and the login page can be changed to whatever you like. See the configuration details below.
ConfigurationThe following variables can be defined before userauth.php is included in config.php: $GuestUsername - Specifies the username that is used by default when no user is logged in. $LoginPage - Name of the page which has the "(:loginform:)" markup on it to display the login form. $LackProperAbilitiesFmt - Message displayed when the user unsuccesfully tries to login. $UserInfoObj - Specified the object used to obtain information on users and their abilities. By default HtPasswd.php will be used to grab user information unless the $UserInfoObj is already set. This allows someone to write a new user info object that gets its information from a database or some other format. This new class would only need to implement the contract as can bee seen in the HtPasswd.php file. Only implement those methods below the line that says something to the effect in that file. $HtPasswdFile - Alternative location of the HtPassword file. Not used if $UserInfoObj is set to a different object before the script is included in config.php. Note: if you want to set up a wikifarm field to use a different HtPassword file, just set $HtPasswdFile to "local/.htpasswd" in the field's index.php before including the wikifarm copy of pmwiki.php. $UserInstanceVars - Defines the class that manages user information such as username and password for the instance. This information is for the current logged in user, or blank if the person accessing the site is not logged in. The default class, UserSessionVars will be used unless this variable is defined before UserAuth is loaded. If someone wants to handle instance user information with a method other than the $_SESSION array then create a class that has the same contract as UserSessionVars and set this variable. $RedirectToPrevious - This variable determines if upon succesful login or logout UserAuth redirects to the page that originally called the login or logout action. The default is true. If for instance you want to always redirect to $DefaultRedirectionPage then set this variable to false. $DefaultRedirectionPage - If there is no information about which page orignially called the login or logout action then redirect to this page. The default is to redirect to Main.HomePage when there is no previous page information. One could possibly write a script that gets called before UserAuth and sets up this variable based upon things such as the current group, username or whatever. $UserAuthAllowCookie - Defaults to true, which allows a cookie to be used to store username and password information between browser sessions. The password is stored in its encrypted form. V0.70 $UserAuthCookieExp - The expiration time for the cookie, in seconds. Defaults to 30 days. V0.70 Userauth-NewUserThis creates a form that allows users to request a new account. By installing this, you receive the (:newuser:) macro. This macro creates a form asking for the Username and Email address. When completed, the form data is then emailed to the email address in the form, sent by the $SiteAdmin email address. The user is then instructed to reply back that email. This ensures there is a real user who will receive the account. This is an alpha. It lacks all customization and documentation. I wrote this before the later builds of userauth where the admintool and other scripts were added. I hope those who are working on this can find use for it. I presently use it to arrange for user accounts on three web sites--although before I started using userauth-admintool. BenWilson Here's an idea for how to use this script--that is the perfect solution for my needs. Maybe it will help someone else. When user fills out the registration form, get their confirmation email, and reply, it goes to a simple autoresponder which gives them a password for authuser! Plus it forwards their verified email on to me to add to my mailing list which is the whole reason I had them sign up in the first place. Caveman
Userauth-RegisterThis is a much more trusting version of the above script, which automatically creates the user immediately. No email is stored. Use macro (:registerform:). It detects password mismatch and username-already-taken type errors, but not much more. It would be nice if it incorporated some sort of CAPTCHA or email verification, but right now, it doesn't. Note that this enables anyone to get LoggedInUser privileges for free. GregManning? After enabling the userauth-register.php script, my RSS feeds stopped working. Disabling userauth-register fixes RSS. Is there a fix avaiable for this item so I can use both RSS and userauth-register? Thanks TRhodes July 19, 2006, at 03:33 PM Thanks to ErnieLogan for this workaround: if ($action != 'rss' & $action != 'atom' & $action != 'rdf' & $action != 'dc')
require_once("cookbook/userauth-register.php");
HTML CustomizationThe HTML that is displayed on the LoginPage can be easily changed. By default the [loginform] inline replacement calls a function that returns the login page. To specify different HTML then either redefine the definition of [loginform] in the Markup() or use some other method that correctly calls the login action. If you wish to change your template to include a link that displays "Login" or "Logout" depending on whether or not a user is logged in then add the following to the template: <a href='$PageUrl?action=$LoginAction'>$LoginName</a>
The $IsUserLoggedIn variable can be use with the conditional directive. To use it you need to add something like the following to you config.php: $Conditions['loggedin'] = "\$GLOBALS['IsUserLoggedIn']==\$condparm";
Then you can use the following markup to display certain page data only for logged in/out users: (:if loggedin:) You are logged in (:if:)
(:if !loggedin:) Please login (:if:)
There is a new conditional variable member that allows to check against a specific user group membership V0.70 (:if member @editors:) conditional text (:ifend:)
The .userauthinput and userauthbutton CSS classes can be used to control the look of input fields and buttons defined in the userauth class History
See AlsoCheck out the EvolverSkin? for examples of how to integrate UserAuth and CMSLike functionality into a skin. The AuthUser recipe explains how to use a passwd-formatted (.htpasswd) file for user-based authentication. Notes and CommentsAdditional comments, bugs and suggestions are always welcome on the UserAuthDevel page. Please try to debug any bug as much as possible to help the problem get resolved faster. Also when commenting please refer to the version of the software you are using. Pagelist not showingIf your pagelist are not showing for users like guest it might be because guest doesn't have permission to read your PageListTemplates page. Add the permission: read_page-Site.PageListTemplates to your guest account and the problem should resolve. -CMH
Expiration of Session Author and Contributors
Pardon, I really couldn't work out where I can put questions, so please delete this, if it is not appropriate here... I tried to install the script, uploaded the files and everything, and then after loading my page again I got this: UserAuth should allow GuestUser to be given access to certain public areas, eg page groups "Main" and "MyPublicStore" for example. In userauth.php line 465, replace: if($UserInfoObj->UserHasAbility($GuestUsername, "read")) {
with: if(UserAuth($pagename, 'read', False)) {
(jonw at improov dot com) There's a bug with UserAuth's integration with PmWiki's authentication. Group-level access is obliterated by page-level access control flags. To reproduce: Create a user UserA with abilities read_group-GroupA, edit_group-GroupA. Create 2 pages GroupA.pageOne and GroupB.pageTwo . UserA can read and edit both pages. Now, enter "id:UserA" into GroupA.pageOne's access control. You'll see that UserA can no longer edit GroupA.pageOne .
Seems to be a missing link or bad integration with PmWiki's authentication routines. (jonw at improov dot com) How use this recipe with MySQL? I want to integrate it with [(approve links) edit diff]. I'm a little confused concerning this recipe. Is it recommended to use this in combination with AuthUser or are they mutually exclusive? I use AuthUser on one site already and it works pretty well but I was hoping to beef up the user accounts with more information and make the user permissions easier to manage. However, I'm having several issues and I'm not sure if they are inherent or pebcak.
Thanks, Hi, Bill. Thanks for introducing me to the word pebcak.
Hope this helps! Ben Stallings March 28, 2007, at 08:05 AM Hello Bill, AuthUser and UserAuth are NOT supposed to work together - they are as you thought mutually exclusive. Protecting individual (i.e. single) pages using UserAuth should be fairly easy, unless you meant personalized pages. In the latter case have a look at Cookbook.UserAuth2 which is a kind of reimplementation with a lot more features than before. It should also give you the power to "beef up the user accounts with more information", creating "MyWiki" pages readable by the corresponding user only, etc. (see UserAuth2.Help). ThomasP March 31, 2007, at 11:35 PM Hi. I didn't seem to get the $DefaultRedirectionPage to work. I went and looked into the userauth.php code and replaced the $_SERVER['REQUEST_URI'] with
$_SERVER['HTTP_REFERER'] in the form action.
Now the Main.LoginPage redirects as it should, at least for me. But how should this be working for real? I am attempting to install the UserAuth and following the instructions I get confused at this point, "Include the plugin from your config.php file: require_once("cookbook/userauth.php");" I don't have that in my config.php. am I missing something or misinterpreting. I am new to php so I could be confused. Thanks for any assistance AJ Oct, 9 2008 blazn40@gmail.com See Initial Setup Tasks for some information about See also How To Get Assistance and Local Customizations. Note you might be better to use UserAuth2 CopyrightCopyright 2004-2006 under the GNU GPL License User notes? : If you use, used or reviewed this recipe, you can add your name. These statistics appear in the Cookbook listings and will help newcomers browsing through the wiki. |