• View
• Edit
• History
• Attach
• Print
• Backlinks

UserAuth2

Overview

This is an authorization and authentication module for the pmwiki engine, originally intended to be a reimplementation of the Cookbook.UserAuth module. It provides a flexible way of granting permissions on a per-user basis via a typical web interface, and password or - subsequently - cookie based authentication. The main motivation was to fix the bugs in the former module systematically and on the way introduce the possibility of sharing/delegating administrative tasks (like creating users, assigning them permissions) with other users. See a complete list of changes compared to the former module here. (LDAP support was added in version 2.1-beta2.)

Live showcase

I have put up a live example of this module at http://www.sigproc.de/ua2_showcase65/. A sub admin account can be accessed via username "small_admin", password "pmwiki". It allows access to the admin tool (click "Admin tool" next to the action links), creation of users and unlimited access to groups starting with "Test".

Files

• userauth2.2.3-php7.2-fix3.zipΔ (2019-04-27) (stable) (Changelog, Known issues)
  

containing:

 userauthx.x.x/
   README.userauth2
   LICENSE.userauth2
   UPGRADE.userauth2                <- find information about how to upgrade here
   userauth2.php
   userauth2/
     .htaccess
     UserSessionVars.php
     userauth2-permchecklib.php
     userauth2-admintool.php
     userauth2-pwchange.php
     userauth2-bruteforce.php
     Site.Login
     UserAuth2.EditUserQuickReference

Installation

Unzip the package file and copy the contents to the cookbook directory. Move the file userauth2/Site.Login to wiki.d/ and userauth2/UserAuth2.EditUserQuickReference to wikilib.d/. Add

 $HomePage  = "Main.HomePage";       // should use dots (instead of slashes) even when using
 $LoginPage = "Site.Login";          // CleanUrls ($EnablePathInfo=1)
 $HandleAuth['diff'] = 'history';
 include("$FarmD/cookbook/userauth2.php");

to your local/config.php and adapt the home page setting to your needs. (It is needed for some default redirection.) The login page can be renamed/moved around BTW (provided you adjust the local/config.php), but make sure it is non-editable. The HandleAuth line can be omitted if no designated permission level for accessing the page history is needed.

Upon the first run of the module, an 'admin' user will be created with a default profile containing an empty password. Change this later, e.g. by calling

 http://www.foo.bar.com/path/to/my/wiki/pmwiki.php?action=pwchange

while logged in as 'admin'. Besides a guest user group will be created, with read-all access (except for the SiteAdmin group) set as default. You can change this as you like. You can also define a group "LoggedInUsers" whose rights are granted--as the name suggests--to all users that are logged in (i.e. are identified to the system with non-empty user name).

That's it. I have put up some help below on how to get the permission setup started. As the module slowly starts to mature, I expect no immediate bugs to be discovered anymore. If there still should be one, or if you have questions/suggestions, leave a comment below or ask on the pmwiki mailing lists (usually pmwiki-users is best). For development related details it might be also useful to contact me directly (email can be found here).

Remark1

To ensure a defined session expiration behaviour and for various security reasons, this module directly sets the session save path to a sub dir in the userauth2/ dir. (This directory will be automatically created.)

Remark2

There has been a long-standing failure (reported often for (apparently) Windows PHP5 installations) where the session functionality was broken, in the sense of "forgetting" the login directly after passing the correct password to the wiki. (Thus no actual login was possible.) The problem was known not to be caused by UA2 code and could roughly be drilled down to the session file not being correctly written due to a faulty PHP session support. This problem now seems to be solved, with Jerome reporting that upgrading to PHP 5.2.8 helped (see comment below, 2009-02-12). Please add any relevant observation below to the comments.

Useful markup

To get some login/logout links, the following markup might serve as example:

(:if loggedin:)
* [[Logout ({$AuthId}) -> {$FullName}?action=logout]] \\
(:if:)
(:if ! loggedin:) 
* [[Login -> {$FullName}?action=login]] \\
(:if:)
(:if auth admin :)
[[{$FullName}?action=admin | $[Admin tool] ]]
(:if:)

Simple usage

Setting permissions is done by manipulating the permission tables of the various users/groups. For this call up the admin tool via

 http://www.foo.bar.com/path/to/my/wiki/pmwiki.php?action=admin

while being logged in as admin (or as someone who has admin tool rights). Then, to grant rights specify a list of permission entries in the permission table of the respective user (create a new user first). The common entries take the form

 LL_ggg.ppp

where LL is rd, ed, up or hi, denoting the permission levels read, edit, upload and history. (Here "upload" means that the user may upload files to the dir corresponding to this page, and "history" that she may view the history.) You can also use xx which matches all page related levels. The ggg.ppp is the part specifying for which page the right should be granted. You can use typical wild cards to target a set of pages/groups.

Prepending the whole entry with a '-' (minus) exactly withdraws the right. For this purpose the entries in the permission table are interpreted in the order they occur, with the final applicable entry setting the result.

For example a typical guest user permission table might look like this (this is a suitable permission record for pmwiki 2.2.0-beta58 or above, previous example here)

rd_*.*,
-rd_SiteAdmin.*,
ed_Home.Feedback,
xx_Playground.*,

It makes the whole pmwiki readable, with exception of the 'SiteAdmin' group which is reserved for pages intended not to be publicly available (since pmwiki 2.2.0-beta58). Additionally a feedback page is editable, while the complete Playground group is freely accessible.

Help on options / advanced features

Find documentation on the topics below on the documentation page.

• How to authenticate against a LDAP server
• How to set up ip based silent permission granting
• How to set ip based login restrictions
• How to change the default redirections after login/logout
• How to enable/customize persistent logins
• How to disable/customize brute force attack prevention (enabled by default)
• What wild cards can be good for
• How to create personally accessible pages (using {$AuthId})
• Delegating permission granting / Multi admin setups
• How to introduce new permission levels for certain actions, like for "publish", "comment" etc.
• How to change one's own password as a user
• How to create a new user as a non-admin user
• How to use the recipe with SSL

Bugs

If you discover a bug in the system and like to do some debugging, you might consider getting my debugMsg() function (can be found at ThomasP). With this you can use the internally already set up debug facilities.

In general when encountering a bug, have a look at the KnownIssues first, and have a light skim over the mailing list archive to see whether something is said about it already. When reporting, please quote your pmwiki and PHP version.

If you like to contribute to development and have some larger comments, please leave them on UserAuth2-Talk.

See Also

Related modules

• Cookbook.UserAuth (the former version of this module)
• PmWiki.AuthUser ("the" other user-based authorization module shipped with the standard distribution of PmWiki; find a comparison here)
• Cookbook.MemberMgmt (a comprehensive membership management module)

Others

• UserAuth2.Comparison (changes of this module relative to the former module)
• UserAuth2.ModuleChoice (comparison of this module with AuthUser)
• UserAuth2.Help (main place for documentation)
• UserAuth2.ExampleSetups (to get a glimpse of the full power of the module)
• UserAuth2.KnownIssues (known issues, to do, roadmap)
• UserAuth2.Changelog
• UserAuth2.ImplementationReference (description of every detail of this module)
• UserAuth2.SupportForApachePreAuth
• mailing list article describing some features of this module

Contributors

• ThomasP (original version)

Small user survey

I'd like to know who is actually using this module. Just manually count up numbers:

• new user (first time at pmwiki for no more than 3 months): 21
• "old" user: 12

(started April 2007)

Comments

This space is for User-contributed commentary and notes. Please include your name and a date along with your comment. Optional alternative: create a new page with a name like "ThisRecipe-Talk" (e.g. PmCalendar-Talk). See Discussion at UserAuth2-Talk

The skript works very well - great work! But when I want to login with setting a cookie the following is returned:
Fatal error: Call to undefined function: get_rand_session_id() in [...]\cookbook\userauth2\UserSessionVars.php on line 200 How can I fix it? Tx a lot! Michael November 16, 2007, at 03:04 PM
Fixed it by replacing line 200 in UserSessionVars.php by $randKey = microtime();. It works, but I guess there shall be a more professional soulution. :-) Michael November 17, 2007, at 02:03 AM

Hope this isn't a stupid question, but where exactly does the permission table content go - in Site.Login, the userauth2 php file, somewhere else? I took a look at UserAuth2.ExampleSetups and it also does not say where one would place the settings. Thanks for any help. -Matt

Log in as admin then go to the admin page by appending ?action=admin to any url

For the user or group you want to give the permission to click on edit.

In the form displayed there is a box Permissions granted by. table content goes here.

I had to think about this, but it works well -Dave

Yes! Thanks for the help, all good now. -Matt

It seems that my 'http://url.com/pmwiki/pmwiki.php/Site/Site?action=admin' has bad links all around. Could it be because I set "$EnablePathInfo = 1;" ? All the links on that page are rendered 'http://url.com/Site/Search' or url.com/Site/Site?action=edit < all dead links. Thanks - Kevin - Profiles

I am trying to implement the UserAuth2 and I am having some difficultly. I have my user with admin rights but whenever I type in the password, it displays the "incorrect password" message. It should be the correct password, I say this because earlier I was able to change it from xxxx to yyyy and it was saved successfully. Any ideas?

Hi, I always lock myself out when editing users/groups: "Cannot proceed. This record is locked by someone else for editing. Please try again later.". Because of trouble with my hoster (disturbing error comments) I uncommented all lines beginning with ini_set in userauth2.php (about five around line 210). Could this be the source of the error? peter February 26, 2008, at 12:14 PM

The error message is: "Warning: ini_set() has been disabled for security reasons in /usr/export/www/host...." and from what I understand big part of the cookie game is managed in these 5 lines. Any ideas for work around? peter February 26, 2008, at 12:49 PM

It's not the cookies. The 5 mentioned lines can be discarded. But I found files called after the locked out groups in the userauth2/groupperms folder. They seem to have timestamps. Deleting them solved the problem.

Hi, after i installed the package I get the following errors..
Notice: Session table unacceptable in /www/global/script/sessions.php on line 88
Warning: mysql_real_escape_string() expects parameter 2 to be resource, null given in /www/global/script/sessions.php on line 108
(plus I dont think I have farms enabled. Im just looking to add basic user authentication to my new pmwiki install)

October 02, 2008, at 12:53 PM

Feature list of what might be essential: ThomasP September 02, 2009, at 09:28 AM

• profile information storage (mainly email)
• captcha (at least preparation)
• email verification needed?
• admin approval of new registrations

I would suggest we have a voting at this very place: (everyone needing this please add a star below, possibly with some name and date)

• Nigel, 05/2009

 [Wed Jun 15 11:11:26 2011] [error] [client 172.23.1.161] PHP Warning:  
 fgets(): Length parameter must be greater than 0 in 
 /home/paul/public_html/w/cookbook/userauth2/userauth2-permchecklib.php 
 on line 822, referer: [(approve links)
  edit
  diff]

It is a great recipe, I discovered it for JITS which is also very convenient.

Unfortunately, despite having userauth2.2.3 (2010-03-03) and PmWiki 2.2.36, both latest versions as of today, I do not have pagelist working, neither directly nor as search result. I read in UserAuth2-Talk that it was fixed a while ago, I even read through the mailing comment yet I can not figure out why it is broken and how to make pagelist work again.

Utopiah February 09, 2012, at 10:49 AM

"Upon the first run of the module, an 'admin' user will be created with a default profile containing an empty password. Change this later, e.g. by calling "

Figured out how to reset the admin password. Delete the admin file in cookbook/userauth2/profiles This will reset the admin password to blank. Goto yoursite.com/pmwiki.php?action=pwchange and this will let you enter a new password.

An addendum to Remark 1:
You can override this session_save_path behavior by adding the following line to config.php before including the cookbook/userauth2.php:

## Prevent UserAuth2 from changing the default session_save_path
$UA2SessionSavePathDir = session_save_path();

The problem I was experiencing is that PHP is unable to use a directory as the session_save_path if that directory is not owned by the web host, and this was not a sane option with my wiki stored on an NTFS-3G mounted Ubuntu file system (It runs in Apache2 on Linux, or IIS if booted to Windows 10.)

It is also generally useful to be able to configure this setting, so as to ensure the session data storage is on a file system that is good for quick reads and writes of lots of small files.

~~ Damien Palmer July 13, 2017, at 02:22 PM

• userauth2.2.3-php7.2-fix3.zipΔ

userauth2.2.3-php7.2-fix3

This is a patched version of userauth.2.2.3.tgz that fixes some issues that are caused using UserAuth2 on PHP 7.2. These issues cause numerous warnings to appear in de Apache2 error log like this:

	PHP Warning: Use of undefined constant someidentifier - assumed 
	'someidentifier' (this will throw an Error in a future version of 
	PHP) in {file} on line {number} 

and also:

	PHP Warning:  count(): Parameter must be an array or an object that 
	implements Countable in {file} on line {number}

These warnings are all caused by a old style of PHP programming in UserAuth2 where sometimes strings where passed without quotes. When this happens, stricter type checking introduced in PHP 7.2 causes many warnings to be logged in Apache2 error log.

define(UA_ADMINTOOL, '2.0'); changed to: define('UA_ADMINTOOL', '2.0');

if (!function_exists(microtime_float)) { changed to: if (!function_exists('microtime_float')) {

Disabled some lines of debugging code at lines 330-334 in userauth2.php.

~~ PaulWiegmans Apr 27, 2019 at 16:45