This is a talk page for improving AuthUser.

AuthUser & Farm-Wikis

I need a bit more concrete hints for handling AuthUser within wikis in a farm, if wiki1 should be readable for all visitors, while wiki2 only should be readable for login-users. Especially I’m not sure, where to place the include of authuser.php. But – after very long searching, I’d wish I could have found such a hint clearly and directly at AuthUser – I bet it could work like this:

$AuthUser['htpasswd'] = 'path/to/.htpasswd';
$AuthUser['htgroup'] =  'path/to/.htgroup';
$DefaultPasswords['edit'] = '@wiki-editors';
#NO include of authuser.php here, while it will destroy all settings – correct?

$DefaultPasswords['read'] = '';

$DefaultPasswords['read'] = '@wiki2-readers';

Am I right: The include of authuser.php must NOT be placed in the farmconfig.php, but should be included in every local/config.php ?

Thanks for all helpful hints and answers!

Yes, this looks good. --Petko November 07, 2017, at 02:40 AM

Setting single page permission.

Is there a way to set read-only permission to single page, after setting de default $DefaultPasswords['edit'] and $DefaultPasswords['read']?

Yes, follow a link like [[Main.HomePage?action=attr]] and in the form set the read password for the page to @nopass (open for everyone), @lock (locked for everyone except admins) or any actual password. See Passwords. --Petko September 08, 2016, at 01:01 PM

Can this be done also from config.php and not from browser url and form?

Not in a secure way. --Petko September 08, 2016, at 02:22 PM

Marcus Denning,, 20160202-12:35GMT-06
When using Option: User List on Site.AuthUser
The following pertains to Username, Password, and Profile pages combinations when using AuthUser Wiki pages for group/user Authentications.

If only the password is used for authentication, how can the name assignment be verified or changed appropriately so that there is not an author of name 'blank' or "Profile" showing up and regardless of the login author name a valid profile page can be reached?

This is going to be a bit of an involved one. I have literally just taken snippets of code and figured out how to implement them in this one. I am pretty sure someone can figure out how to do it better. However, this solution seems to work and is letting me display a valid profile page to reach without blanks or the name "Profile" for the AuthorName.

First, I have this little snippet of code in my NavBar header (another CookBook plug-in) that shows the profile selection and login auth selections appropriate to the login.

(:if ! enabled AuthPw:)
* %item rel=nofollow class=login  accesskey='$[ak_login]'%   [-'''%color=#880000%[[{*$FullName}?action=login | $[Login] ]]%%'''-]
(:if enabled AuthPw:)
(:if2 auth admin:)
* [-[[Profiles.{$Author} | %color=#660000%'''''{$Author}''  - '''%%%color=#ff0000% ''Profile''%%]]-]
* %item rel=nofollow class=logout accesskey='$[ak_logout]'% [-'''''%color=#ff0000%[[{*$FullName}?action=logout | $[Logout] ]]%%'''''-]
* [-[[Profiles.{$Author} | %color=#660000%'''''{$Author}''  - '''%%%color=#00ca00% ''Profile'' %%]]-]
* %item rel=nofollow class=logout accesskey='$[ak_logout]'% [-'''''%color=#00ca00%[[{*$FullName}?action=logout | $[Logout] ]]%%'''''-]
(:if auth admin:)
* [-[[Site/Site | %color=red%Site Admin%%]]-]
* [-[[Site.SiteMap | %color=#0000aa%Site Map%%]]-]

Then, in my local/config.sys file, I have done the following.

  • First I made a variable out of the Master Password to make it easier to change if needed.
    • $AdmPass = crypt('MastPass01');
      $DefaultPasswords['admin']   = array($AdmPass,                 # global password
                                          '@admins',                 # +users in these groups
                                          'id:Daniel', 'id:Marcus'); # +users individually
      $DefaultPasswords['upload']  = array($AdmPass, '@admins', '@moderators', '@editors');
      $DefaultPasswords['edit']    = array($AdmPass, '@admins', '@moderators', '@editors', '@writers');
      $DefaultPasswords['publish'] = array($AdmPass, '@admins', '@moderators', '@editors', '@writers');
      $DefaultPasswords['delete']  = '@lock';                        # DeletePage CookBook plug-in addition
      $DefaultPasswords['attr']    = array($AdmPass, '@admins');
  • Then, after all that, I get to my Login Name testing to select the right name.
    • ## Enable authentication based on username.
      if (  $AuthId=='admin' ) {$Author = $AuthId; } # after include_once(authuser)
      if ( !$AuthId=='admin' )
      { if ( (  $AuthId == '' ) || ( $AuthId == 'Profiles' ) )
        { if (  $authpw == $AdmPass ) { $Author = 'admin-X'; }
          if ( !$authpw == $AdmPass )	{ 
            if (  CondAuth($pagename,'admin') ) { $Author = 'admin-X'; }
            if ( !CondAuth($pagename,'admin') ) { 
              if ( CondAuth($pagename,'upload') || CondAuth($pagename,'read') || CondAuth($pagename,'edit') ) { $Author = $AuthId; }
              $Author = 'Rogue-X';

The final result of all of this is that when someone logs in they see their own login name at the top with a link to their own profile page. If they have the incorrect username and the correct password, the system authenticates but strips out any special admin/edit auths per the AuthUser plug-in functionality (goverened from within the AuthUser Wiki page by groups/users auths). If the latter happens, then Rogue-X shows up noting they had the incorrect login name and therefore the username is not a blank or the name "Profile" by default. In addition, the UserName Rogue-X can be assigned any rights desired in the AuthUser Wiki page. By Default, Rogue-X is simply a name and has no rights anyway. The Site Admin username is selected as either admin or admin-X as long as the correct password is entered, however the admin auth status is not stripped. Any edits that happen as admin or admin-X will simply show up as that AuthorName.

I really hope this helps someone. It took me a while to figure out the logic, but it seems solid for now.

Rarely asked questions

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.

if i already specified a group in local/config.php, then i set the same group on SiteAdmin/AuthUser then will it merge all users in that same group?

It is supposed to work this way -- in config.php you set for example:

  $DefaultPasswords['edit'] = '@editors';

then, in the page SiteAdmin/AuthUser you define all users of the @editors group:

  @editors: Alice, Bob

I want to allow anyone to edit my wiki, but don't want anyone else to use my name as the author.

Is there a way to "reserve" and password protect certain usernames? Or basically just require a password when attempting to edit a page with a registered user's name in the author field?

Yes, use such a code in config.php:

  ## Preventing others posting as "Pm" or "Petko"
  if( preg_match('/^(Pm|Petko)$/i', trim(@$_POST['author'])) ){
    $DefaultPasswords['edit'] = '@lock';
    $MessagesFmt[] = "To post as '{$_POST['author']}' please log in.";

This will display the authentication form when a user tries to post as Pm or as Petko. Note that these users need to know the admin password to get through.

-> Q: but how to do this for groups of users? - BlacK? June 14, 2018, at 10:49 PM

If you set in config.php include_once("$FarmD/scripts/authuser.php"); $Author = $AuthId; then any username typed by unregistered users will be ignored, the page histories will simply store the IP addresses. Registered users before editing will need to first go to ?action=login to log in; you may want to add a warning wrapped in a (:if authid:) conditional in Site.EditForm. --Petko June 15, 2018, at 09:31 AM

not working? got this:

 $AuthUser['htpasswd'] = '.htpasswd';
 $AuthUser['htgroup'] = '.htgroup';
 $Author = $AuthId;
 $DefaultPasswords['admin'] = 'id:Admin';

+captcha set up. +default edit password is not set.

still writing any written name+ip into page history - BlacK? June 15, 2018, at 04:28 PM

Not-answered questions

How can I access the authorization groups that the current user belongs to in order to test using that as a condition of an if statement?

forceflow: Dirty hack I found: create a lone page (DirtyHackPage) somewhere, and only give a certain group (apples, for example), the rights to read it. Then you can use (:if auth read DirtyHackPage:) to identify members of the apples group. It's dirty, but does the trick if you only have limited amount of groups.

Is there any way to have groups inherit other groups (e.g. @fruits: @apples, @oranges, jack)?

See PITS.01232Eemeli Aro

Is it possible to list more than one .htpasswd and .htgroup file to be used?

e.g. if I am running a wikifarm and some users are common across various fields, it would be nice if they only needed to update their password once. Sure I could merge all the passwd & group files, but then I wouldn't be able to support identical user or group names on each independent wikifield..

I'm facing a problem with authentication using MySQL database.

New user registration works but login always fails asking for correct user name and password even though proper values are entered. Where could be the problem?

I have been trying to set site-wide authorizations and getting really frustrated. I have the following lines in my config.php:

 $DefaultPasswords['edit'] = crypt('edit_password');
 $DefaultPasswords['read'] = crypt('read_password');
 $DefaultPasswords['admin'] = crypt('admin_password');

But I can still freely edit many pages. Some not, some yes. I've tried manually "clearing" passwords on pages that I seem to be able to edit.

What gives?

Is there a way that people could self-register through AuthUser?

Chris I'm trying to do this same thing now via phpbb 3.0's authentication and database. If that's an option here's how I plan on doing it. I have the phpbb 3.0 working with an sql database thanks to godaddy. I think all you need are 4 other cookbooks, AuthUserDbase dependent on AuthUser, ADOdb, DatabaseStandard. I'm going to use Cookbook:AuthUserDbase "setting for using another program's database for authentication. Then I'll need to figure out how to set user permissions to their own created content. I'd love to package all 4 of these cookbooks, and some default lines to add to a config.php to enable any new pmwiki hosts to easily connect to an existing database with minimal "dirty work". Best of luck to us both, Mark (reach me at the site I'm building is

Please see Cookbook:AuthUserSignup for a solution to this problem. Peter Bowers October 25, 2008, at 01:45 PM

This is totally true! I've been working with Peter on getting this installed and I can truly say that this is the most complete authentication system for AuthUserSignup. Real Chris November 19, 2008, at 05:15 AM

I use the SiteAdmin.AuthUser page to create user accounts at my wiki. Now, I have three on there now (big site, really). Two I created some time ago (like 2 years ago, or something) that are functioning correctly, but a third that I've recently created, and I can't get this guy working. I have entered and re-entered various times, the same as for the others:

# username: (:encrypt somepassword :)
  1. username: $1$o4iUYvYF$cZh46pfprMsAIDEhRs.kQ1

and the guy can't get in with the assigned username and password.

I am confused by this.

This site is running pmwiki-2.2.27 (VersionNum=2002027).

Please forgive the xpost. I asked this question on another page, but this seems the appropriate place.

tonybaldwin September 25, 2011, at 10:54 AM

Remove the "#" at the beginning of the line before username. --Petko September 25, 2011, at 12:04 PM

Okay, I tried that, but it didn't make a difference. I didn't think it would, since the other users are listed in the same fashion, with a "#". I appreciated the attempt, all the same.

tonybaldwin September 27, 2011, at 06:38 PM

AuthUser ignores lines starting with # so it shouldn't be before any line with username:password. Other things to check: the password cannot contain spaces, tabs, new lines, columns ":" and equals "="; on some systems it should be at least 4 characters long; usernames and passwords are case sensitive. Does another password work with the same username? Does another username work with the same password? --Petko September 27, 2011, at 07:25 PM

Reserving author names - A question like this was asked below, but it doesn't seem to work for me, perhaps it worked with an older version. I have enabled AuthUser and created some accounts. I have one page, however, that I have set the edit password to @nopass to allow for anyone to edit it. I would, however, to not have anon users be able to use specific names as the author (like that of the admin, for example). I've tried adding the recommended lines to my config file with no success. Any suggestions? Thanks!

Here is what we use on this wiki to prevent others posting as Pm or Petko:

  $postauthor = stripmagic(trim(@$_POST['author']));
  if( preg_match('/^(Pm|Petko)$/i', $postauthor) ){
    $DefaultPasswords['edit'] = '@lock';
    $MessagesFmt[] = sprintf("To post as '%s' you need to log in.", $postauthor);

Error message when logging in

I have set up a new wiki installation with AuthUser enabled. When I log in via ?action=login, everything works as expected. When I then log out again on a read protected page, I am redirected to a login prompt. Logging in via that prompt works, but causes the error messages "Deprecated: crypt(): Supplied salt is not valid for DES. Possible bug in provided salt format. in [redacted]/pmwiki.php on line 519". I have already found the explanation that this is most likely due to the use of the crypt function instead of pmcrypt, but I have not found the error anywhere. This seems like a bug in AuthUser to me. Can someone help? Thanks! Mierk? March 27, 2018, at 02:21 AM

See Troubleshooting#crypt on how to track down some old pages that may need updates. --Petko March 27, 2018, at 05:01 AM

Yes, thanks for answering. I know this page and have looked for the problems described there. So can you confirm that this is a problem unique to my installation? Then I will continue looking. Thanks! Mierk? March 27, 2018, at 09:42 AM

It is also possible, in rare cases, that specific (older, Windows) PHP versions created hashes that are not compatible with more recent PHP versions (especially if the passwords are too short, eg 4 characters or less IIRC). If this is the case and you re-type your password in the ?action=attr prompt, your hash should be updated to something that is recognizable. If this is a PmWiki bug you are unlikely to be the only one experiencing it, so more people will come forward. (I assume you don't have any addons or customizations that call the pmcrypt() function, or we should review those.) --Petko March 27, 2018, at 02:01 PM

Unfortunately that's not it either. These are all new passwords that I generated a few days ago using Ubuntu. Just to be sure I just tested setting a new password for a user on the SiteAdmin/AuthUser site via (:encrypt newpassword:), as well as for a specific page with ?action=attr, still the same error. I tried disabling all recipes except AuthUser, no change. I wonder why this error does not occur when logging in via ?action=login. Mierk? March 28, 2018, at 02:36 AM

I am using Ubuntu daily, and tried to reproduce the bug you have, without success. When I open pmwiki.php?action=phpinfo, my PHP version is "", with the latest PmWiki version. The only error I get (not the one you reported) is when I place a colon ":" in the page password -- this is not allowed and no password is stored. If I had access to your server I'd do a backtrace and print the hash that is compared. Can you confirm your wiki doesn't contain "page files" (in wiki.d or wikilib.d) that contain among their first few lines the lines passwdread=* and/or passwdedit=*? I'm not sure what else to try. --Petko March 28, 2018, at 01:36 PM

Thanks for your help, Petko! I think I narrowed down the error pretty well now. I did a completely new install with just the following changes:

  • move sample-config from docs to local, rename to config.php, change the wiki title (for clarity) $WikiTitle= 'TestWiki';
  • set passwords: $DefaultPasswords['admin'] = array(pmcrypt('secret'), '@admins');
  • include_once("$FarmD/scripts/authuser.php");
  • (also set the right permissions for wiki.d and config.php)
  • go to SiteAdmin.AuthUser, replace the page content by
   !!Login accounts
   mierk: $1$8XR6Uzui$3pQn6AaB0nSaDldQ11Sjd1
   !!Authorization groups
   @admins: mierk
  • logout, login with username mierk -> everything works as expected, I have admin rights, no error messages
  • replace the content of SiteAdmin.AuthUser by
   !!Authorization groups
   @admins: mierk
   !!Login accounts
   mierk: $1$izeCyGE7$N7ZDdxfyI8jf/8bM/ZDoh/
  • log out, log in as mierk -> error message! (still logs in successfully)
  • reversing the order to the group and the account name gets rid of the error :) Did I miss somewhere in the instructions that the order should be this way?
  • also, the error message appears when a wrong password is entered whatever the order of the content of SiteAdmin.AuthUser. But this is less bad in a way because in that case, error messages are expected.

Could you try to replicate this error, Petko? For me, this problem is now ok, I will just leave the content of SiteAdmin.AuthUser in the correct order. Thanks again! Mierk? April 03, 2018, at 06:11 AM edit: my php version is PHP Version 7.0.28-0ubuntu0.16.04.1 Mierk? April 03, 2018, at 06:37 AM

Sorry for the late reply. Yay I was able to see the error message! There are at least 2 things to note here.

  1. The ?action=login function (HandleLoginA) for some reason discards the $DefaultPasswords['admin'] entries, so when you use that action for an admin account it never logs you in Edit: I was wrong, as authuser.php is loaded before that function gets called, the $AuthList array is populated and the admin should be logged in correctly. I'm unsure why this is so, it was done by Pm before I took over and I found no discussion or explanation in the archives -- my guess is this should somewhat prevent automated bots trying to break in -- at any rate if it was done for a reason and people are using it I wouldn't modify it now. This should probably be documented somewhere ("Administrator cannot login via the "?action=login" url.")
  2. The functions that check the passwords will check the password hash, but sometimes also the user groups as if they were password hashes. When your encrypted password is defined before the user group and you type the correct password, you are logged in and the user group is not checked as if it were a hash, so you see no error message. When the @group is defined before the password, it is checked as if it were a hash, and it would be an invalid hash, so there is an error message. (In the past PHP just returned false, so it worked fine.) This will certainly concern many installations and we should fix it in the core -- still considering the implementation.

So thank you for discovering and raising this issue -- great work Mierk! --Petko April 06, 2018, at 05:16 AM

Is there a possibility to cascade different user-groups in a .htgroups file?

Background: I'm using AuthUser via files .htpasswd / .htgroup in a wiki-farm (compare with first post on top of this page). In htgroup I'd like to write something like that:

wiki1-admins: tom petko peter 
wiki1-editors: garry mary sandy

wiki2-admins: @wiki1-admins rosie missie chrissie

Should this usually work? If so, the malfunction of my wiki's got other causes 🙈

Again - thanks for all wailking aids, I'm just crawling around several days :-) Matthias D? May 07, 2020, at 08:00 PM

I don't think nested authentications are implemented. --Petko

Oh, that's the explanation, but it's pritty pity!!! Although that would be a great feature! BUT - thanks for stopping my life in the dark cellar :-) Matthias D? May 08, 2020, at 08:49 AM

This is a talk page for improving PmWiki.AuthUser.