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

UserAuthDevel

Back to UserAuth 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.

22/03/2007

Hello all, I just want to announce that I have a reimplementation of the UserAuth module which fixes all the redirection issues and adds some more flexibility to the permission granting. The module behaves in large parts as the current version (same look and feel), but has a completely new core that also adds some new functionality. It can be found at Cookbook.UserAuth2. Feel free to add any comments or suggestions there or here. ThomasP, 22/3/2007

19/12/2006

Another "redirect after login issue". When using a guest user and Main.LoginPage (contents "(:loginform:)"), the page after login isn't the action the user wanted to take (e.g., edit), but just browsing for that page. This means the user has to click their desired action (e.g., edit) again, which reduces usability. Action path: Main browse > click 'Edit' > Main.LoginPage, log in > Main browse again > click 'Edit' again > finally Main edit

Because of this and some other cosmetic differences, I've tried using UserAuth without a defined Main.LoginPage but still with a guest user. (All the important variable definitions at the top of userauth.php are the defaults.) This seems to work in my testing; you still have to authenticate to perform non-read actions, and the login form is still embedded within the wiki skin, albeit with another H1 tag and the wiki title. The only oddity with this setup I've noticed is only every other login error is displayed. The first bad password / username will display an error, the second bad one won't, the third will, etc.

This setup almost yields the best action path: Main browse > click 'Edit' > Main edit, but with login form instead of content; login > Main browse again > Alternate (1) click 'Edit'; Alternate (2) click browser's 'Back' > finally Main edit

With this "no Main.LoginPage" setup, if I disable the GuestUser and force authentication before any wiki content is displayed, I finally get the action path I want, straight to the edit page after login. However, no GuestUser means, as far as I know, everyone has to have a login even to view content, which is not desirable in my case.

How can the UserAuth redirect be changed to increase usability by sending a successful login to the action page that required the login, rather than the browse page?

pmwiki-2.1.26
USER_AUTH_VERSION, '0.70'
$GuestUsername, "GuestUser"
GuestUser::Guest User:read

john [dot] schulz (at) ndsu {dot} edu
Test Site(approve links)
http://www.ndsu.edu/library/surjeet/wiki/

24/10/2006

I have a question concerning the userauth-newuser recipe. I compared it to userauth-register and tried to add two features to it. First of all i would like to check whether the email is correct and second, i'd like to check whether a Username already exists. The code of the second feature is written in register, but due to my poor php knowledge, I wasn't able to include it into newuser. Any ideas? Florian

21/07/2006

After lots of trying I finally got the redirection work as I like it: after login go to the previous page or to the page that caused the login form to appear. The trick was to abolish the use of the HTTP_REFERER and rather grab the target page directly when we notice that it should be accessed. (This resolves also the problem mentioned by Ben on 23/03/2006.)

ThomasP (pmwiki 2.1.beta25, UserAuth v0.70)

20/07/2006

When trying to use $AuthId as page variable in some conditional markup it didnt seem to be set by UserAuth. I added

  
 $AuthId = $Author;
 

just before

 
 if(strlen($UserInfoObj->GetUserFullname($Author)) > 0) { 
   $Author = $UserInfoObj->GetUserFullname($Author);
 }
 

(near line 107 in userauth.php) to get this working. (Consider renaming $Author to $AuthId globally when doing a redesign to keep in sync with standard pmwiki variable names.)

ThomasP (PmWiki 2.1.beta25, UserAuth v0.70)

19/07/2006

I'm using UserAuth 0.7 + PmWiki 2.1.11

I'm using Userauth-Register to let users automatically register this works fine. It doesn't give them an action in the .htpassword file but I understand that the user picks this up by getting what the LoggedInUser is granted.

When I log in as my newly created user and try editing a page in 'Main', or a new group i created 'public' it first prompts for login with Username and Password (cool), but then it prompts for a wiki password again. Or more regularly comes up with "Insufficient privileges to perform action."

How can I fix this? I believe it has something to do with the LoggedInUser not being able to exercise the permissions. I have set.

I am really quite lost on what to do next.

Any help would be much appreciated. AndyClark?

02/06/2006

I didn't think this would work, but I was curious to see what would happen. I created a user named x\y (not actually x\y, but the equivalent to domain\user or hostname\user). To see something interesting, edit the entry, and save the results (you don't actually have to change anything). Note that a new user gets created (with 2 "\" characters). It would appear that the "\" isn't handled very well. Each time you edit or try to delete one of them another new user gets created w/twice as many "\". You'll have to delete these user entries manually from the .htpasswd file to remove them. I'm using the latest version of pmwiki and UserAuth on a Windows server w/IIS.

What I would really like to accomplish is using http authentication, and place the users names into UserAuth groups. Is this at all possible? If so, I'm sure the $AuthID and/or $Author variables will be filled with the authenticating account, but is there any way to then perform an ldap lookup to resolve a display name (which would then get stored in the $Author variable)? This would REALLY be a great capability if it could be done. I'm I trying to use UserAuth in a way it wasn't designed? Should I really be trying to use AuthUser?

I'd also like to offer a suggestion. I think the "Edit" button should be changed to read "Save", since at that point you are already on the edit page, and the purpose of the button is really to save any changes you have made.

--GaryV

Agreeing with the last paragraph. I have used the following code (after setting of $method_text at the beginning of GetAddEditUserForm in userauth-admintool.php) to get a less confusing commit button:

 
  $commit_link_caption = $method_text;
  if ($commit_link_caption == "Edit")
    $commit_link_caption = "OK";
 

and later

 
  <td align=left><input class='userauthbutton' type='submit' value='$[" . $commit_link_caption . "]' /></td>
 

BTW, I have changed the abilities text area to cols=50 and added a newline character when creating the abilities text, resulting in:

 
 $existing_abilities = join( ",\n", $UserInfoObj->GetUserAbilities($existing_user) );
 

This gives a nicer abilities print out. ThomasP (PmWiki 2.1.beta25, UserAuth v0.70)

01/06/2006

Now that AuthUser has so many of the features that made UserAuth necessary (per-user authentication and usergroups), will UserAuth be deprecated in favour of the default AuthUser functions? UserAuth was the feature that drew me to PmWiki over other wikisoftware in the first place, and I love the feature set, but it would of course be preferable for users to only have to deal with the default installation. What need does UserAuth still fulfil?

25/03/2006

UserAuth 0.7 + PmWiki 2.1.3

Installed userauth-admintool. And use it to

• created group'editor', with ability 'edit_group-Main'.
• Created user 'Jacky' with ability '@editor'.

When editing page in 'Main', it first prompt login with Username and Password, and then it prompts wiki password again. Can UserAuth override PmWiki default password-based protection? --Jacky

I had this problem too. It would be nice if there was an integrated way to handle these default password/authentication issues where all of the info is in one place. Otherwise when you try to tighten up a wiki site to prevent security compromise, and things end up not working, it's not clear what you've done wrong.

23/03/2006

using version 0.70 with PmWiki 2.0.13

I'm having trouble getting the redirect feature to work in a way that my users understand... they like to bookmark password-protected pages and then when they log in they're returned to whatever random page they were previously viewing. I'd like to make it so that it only redirects when the previous page is part of our site, but I'm not sure how to do that. Please advise. Thanks for all your work!
--Ben

05/03/2006

with version .70 I've looked at function UserAuth and CheckUserAuthPassword, and I couldn't help finding something odd,

within CheckUserAuthPassword function
...
$group_specific_level = $level . "_group-" . $group;
if($UserInfoObj->AnyUserHasAbility($group_specific_level)) {
$userauth_level = $group_specific_level;
}
$page_specific_level = $level . "_page-" . $pagename;
if($UserInfoObj->AnyUserHasAbility($page_specific_level)) {
$userauth_level = $page_specific_level;
}
...
if ($UserInfoObj->UserHasAbility($auth_username, 'admin')) return true;
if ($UserInfoObj->UserHasAbility($GuestUsername, $userauth_level)) return true;
if ($UserInfoObj->UserHasAbility($LoggedInUsername, $userauth_level)) return true;
if ($UserInfoObj->UserHasAbility($auth_username, $userauth_level)) return true;
if ($UserInfoObj->UserHasAbility($auth_username, $level . '_all')) return true;

so surely it's ok to have the page/group specific authentication level ($level_paage-$pagename, $level_group-$pagename) in .htpasswd

however within UserAuth function
...
if ( ($userauth_check && $UserInfoObj->UserHasAbility($auth_username, 'admin')) ||
($userauth_check && $UserInfoObj->UserHasAbility($auth_username, $level . '_all')) ||
($userauth_check && ($userpw_wiki_check || $wikipw_wiki_check)) ) {
...
return $page;
}
if (!$authprompt) return false;

why now then it ignores them all together?
-J Lee

14/02/2006

Having a major problem with the Main.Login page redirecting indefinitly with version .70 and pmwiki beta25. It worked great for me since it's release, but I attempted to logout and that is when the redirect problem started. Now I can't access my wiki because any page I attemt to load goes to the Main.Login page, and therefore causes the error. I am esentially locked out until I can find a solution or disable User Auth in my config.php I took a look at the solutions below and none of them worked for me. Any thoughts as to what might cause this?
-Matt
P.S. Big fan of support for groups, thanks!

p.s. I havne't actually looked into why I had the same problem, but if you are not using Main.Login to customize your login form, then just delete the page, once you've disabled UserAuth. After that enable UserAuth extension seems to work fine for me... -J Lee

18/01/2006

Added the functionality to keep a user logged on between browser sessions. Two variables will control the behavior and may be set before including the UserAuth script. If the function is enabled then a checkbox is presented in the login form where the user can decide to stay logged on or not.

$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

$UserAuthCookieExp

The expiration time for the cookie, in seconds. Defaults to 30 days

Also changed that the password is stored encrypted in the session cookie and not in plain text anymore.

I have done some basic testing so far but more testing is required. Please report any problems to webmaster@drwhosting.net

userauth_20060118.tgzΔ

12/01/2006

Fixed a bug with page/group specific abilities when defined as part of the user group definition

userauth_20060112-2.tgzΔ

12/01/2006

Added a reporting page to the administration that shows all users and user groups on one page, with their abilities.

userauth_20060112.tgzΔ

Dan

11/01/2006

UserAuth Modifications

I modified UserAuth to allow the definition of groups and assign individual users to groups. Abilities can still be assigned to individual users as well but the introduction of user groups allows for easier maintenance when there are many users defined. I followed the lead of the new AuthUser module and user groups start with the @ symbol. The administration page now contains two tables, one for users and one for user groups but both are stored in the same htpasswd file.

There is a new conditional variable member that allows to check against a specific group membership

(:if member @editors:) conditional text (:ifend)

Another change I made is the addition of a Full Name field. Instead of just having a username that is used to authenticate there is now the possibility to add the full name of a user, or a group description. The script can read the old htpasswd file and will convert it on the first modification.

Some minor changes to make UserAuth compatible with PmWiki 2.1 finish the list of my changes.

You can download the tgz file here: userauth_20060111.tgzΔ

Please let me know if you find any problems as I have done only limited testing so far. webmaster@drwhosting.net

Dan

22/12/2005

Re: Redirection after login/logout

Using UserAuth 0.64 and PmWiki 2.1.beta14.

Redirection after login and logout weren't working for me. It looks like pmwiki handles them with functions HandleLoginA and HandleLogoutA, which redirect the user back to the login page. I changed pmwiki.php so the calls to those functions now go to HandleLogin and HandleLogout which are defined by UserAuth and redirect the user to the previous page properly.

$HandleActions = array(
  'browse' => 'HandleBrowse',
  'edit' => 'HandleEdit', 'source' => 'HandleSource',
  'attr' => 'HandleAttr', 'postattr' => 'HandlePostAttr',
  'logout' => 'HandleLogoutA', 'login' => 'HandleLoginA');

to:

$HandleActions = array(
  'browse' => 'HandleBrowse',
  'edit' => 'HandleEdit', 'source' => 'HandleSource',
  'attr' => 'HandleAttr', 'postattr' => 'HandlePostAttr',
  'logout' => 'HandleLogout', 'login' => 'HandleLogin');

Cheers, Andy

22/12/2005

Re: UserAuth privileges; Generic login page

I just installed pmwiki and userauth yesterday, so I have whatever the current versions are. I seem to have UserAuth 0.64 and PmWiki 2.1.beta14.

I'm trying to get conditional markup working. I discovered that doesn't work with UserAuth, and I implemented the March 12th workaround. That gives me , which works. Then I started trying to do the same thing for other privileges, like edit or read. The trouble is that I don't have users with the "read" privilege -- in fact, from what I can tell, there is no "read" privilege under UserAuth. There's read_all, or read_group-Main, etc. Is this correct?

Either way, it led to a solution for me: I wasn't getting LoginPage when I clicked a link that required privileges. When I dug through userauth.php to find where the LoginPage gets called, I found the HandleLogin() function. At the point where it tries to display the LoginPage, it checks to see if the user has the ability to read it (and generates a simple default page if the user can't). That part of the function checks for "read" privileges, which my Guests don't have -- they only have read access for the Main group. To solve this, I chaged line 403 from:

if($UserInfoObj->UserHasAbility($GuestUsername, "read")) {

to:

if($UserInfoObj->UserHasAbility($GuestUsername, "read_group-Main")) {

That seems to solve my problem. Am I right about how this is working? Is there a more elegant solution?

Is it possible to create conditionals for other privileges, like to have for those with the edit_group-Blog privilege?

Thanks, Andy

16/11/2005

Analogously to the $DefaultPasswords['pwchange'] issue reported below (which bit me too, so many thanks to those on this page for pre-resolving it!), I found it was necessary to set $DefaultPasswords['upload'] = ''; Otherwise a similar problem arises with UserAuth-controlled uploads.

I have a remaining problem, though: if a user makes an error on user-name or password entry, rather than a PmWiki error message, there's a silent timeout (with IE), or a pause, then a browser error message (with FF: "Redirect limit for this URL exceeded. [...]"). Further, pages previously readable, un-logged-in, then give the same error (or silent failure) if one tries to jump back out to them, without logging in correctly. For example, Main.HomePage, where GuestUser has priv. "read", and can otherwise successfully read the Main. pages. (I also tried adding "rss" as per an example, though I didn't quite understand what that was for...) Tinkering around with $RedirectToPrevious and with $DefaultRedirectionPage doesn't help. I haven't looked at the code, but this looks suspiciously like the erroneous logger-in is losing GuestUser privs. Anyone have any suggestions to resolve, or further investigate?

• PmWiki v. 2.0.13
• UserAuth v. 0.64

-Alex.

Confused update. Experimenting, I gave "GuestUser" admin access(!). If I do this, then I actually get an error page, saying simply "Login to <Wiki>\nWrong username or password supplied.\nUsername: <edit box>\nPassword: <edit box>\n[Login]". But just that on a bare page, no sidebars, etc. And I still can't go from a failed login page to any other page, even if previously readable, without first successfully logging in. (So someone with no valid login, or who has irrevocably forgotten their password, who erroneously tries to log in, is rather royally screwed.) -Alex.

Update with a sense of frustrated completion. Well, I have a fix: unset doesn't seem to be having the correct behaviour, at least in our local version of PHP. (4.1.2. is this too old? Too new? Seemingly the functionality of this changed around 4.1.0.) At any rate, the following diff did it for me:

diff USV2.php UserSessionVars.php
61,62c61,62
<     unset( $_SESSION['username'] );
<     unset( $_SESSION['user_pw'] );
---
>     $_SESSION['username'] = '';
>     $_SESSION['user_pw'] = '';

Trivial, but very painful for a PHP non-user like myself to find. (Even bugging half the lab here for help, at that.) -Alex.

14/11/2005

I solved my pwchange and admintool change/add user problems by adding $DefaultPasswords['pwchange'] = ''; to my config file, changing permissions on local/.htpasswd to 666 and creating a local/.htpasswd.bak file and assigning it 666.

26/10/2005

Hi, My pmwiki installation is a part of web site that is already protected with apache basic auth. Is it possible to pass the REMOTE_USER var to UserAuth, eliminating the double login?

24/10/2005

You probably need to include a blank default password for the "pwchange" action in your config.php. Add the following line to config.php.

$DefaultPasswords['pwchange'] = '';

I am also using 2.0.12 with UserAuth 0.64 and - additionally - CMSLike 0.32. On my site it's nearly the same behaviour of the "pwchange"-parameter like mentioned in the comment before. Only admins can change password, the other users don't even get the link in the action-menu to do so. The "LoggedInUser" with "pwchange"-rights seems not to work. Giving those rights explicitly to a user has no effect too. Any ideas?

24/10/2005

I am using PmWiki 2.0.12 with Userauth 0.64. I created a page Main.LoginPage which contains (:loginform:) but when I want to edit that page again instead of showing (:loginform:) it shows Logged in as: EGN<br><a href="/RP/Main/LoginPage?action=edit?action=logout">Logout</a>. Not sure where it comes from? Also ?action=pwchange only works for people with admin rights ... all others get asked for a password for Main.LoginPage when they click on the change password link I added to the LoginPage Main.LoginPage?action=pwchange. Help please.

Oct 23 2005

I'm using Userauth 0.64 on PmWiki 2.0.10. Very fine !
You described the way to hide a part of the page if the user isn't not logged in. Good.
To go a little further, it could be interesting to be able to hide a link (in SideBar for example) if the current logged in user hasn't the read permission for this destination page (more exactly for the group of this page).

Oct 03 2005

I'm using Userauth 0.64 on PmWiki 2.0.2 I fall in love recently for pmwiki. I'd like to use UserAuth? urgently but i have some difficult to init it. My pb is about how to define a user and password in .htpasswd. I try several things but my site want alaways a password that i can't feeding. Initialy in my /local/.htpasswd i have GuestUser::read , then i can read all without had to login. But if i touch to it, i cant do nothing. e.g: if i just rename in lowercase like guestgser::read , then i cant do nothing, even not reading. I a french man of 35 years. I work in a cinema (the use for i need pmwiki). If you can i'hope contact you on flandriac@free.fr where i'll tell you my msn adress if it'beeter. Thanks Guillaume

Well, you can't rename GuestUser. Usernames like GuestUser are case-sensitive, so UserAuth won't recognise guestuser, only GuestUser.
To add a user account, just add the following to .htpasswd.
Username:EncryptedPassword:edit,upload,whatever else

So if you wanted to have a user by the name of Guillaume with a password of "bienvenue" who had the ability to edit pages and upload files you would put this.

Guillaume:$1$.acEs3jJ$cIz9wyi2gO8PJBbwV9Wvy1:edit,upload

This user will also have any abilities given to GuestUser and LoggedInUser
you get the password $1$.acEs3jJ$cIz9wyi2gO8PJBbwV9Wvy1 by putting ?action=crypt at the end of any pmwiki url and entering the desired password.

-Graham Poole

Sep 30 2005

I'm using Userauth 0.64 on PmWiki 2.0.6 Is there a way to make UserAuth remember a person from their last login? Place a cookie, and then check it when the user returns to automatically log them in? If they click the logout button, it will delete the cookie. I am new to php, and have been trying to do this myself, but can't get it to work properly. I can either get it to place the cookie on login or delete the cookie on logout, but never both. Any help would be appreciated.

- Graham Poole

Sep 29 2005

I have the same problem that Drew described in the post below (the second problem). The only way I can give people upload access is using upload_all. The May 31st post seems to solve Drew's first problem, but not this second one right? I'm using UserAuth version 0.64 with PmWiki 2.0.6. --Tal

Sep 20 2005

I seem to be having trouble with the user_pwchange.php implementation with .64 and 2.0.6. Only users granted admin access in the .htpasswd file seem to be able to change their password, even though I have set LoggedInUser::pwchange in .htpasswd. To test, go to http://www.myfleecevest.com/pmwiki and try to login with l:test p:test and then try to change your password. Meanwhile, when I login with my admin password, I can do ?action=pwchange just fine. Any help appreciated -- Drew

The problems continue. The only way I seem to be able to give people upload access is via upload_all. upload_group-X doesn't work. Any thoughts on why this is? -- Drew

I found a solution using the method mentioned in the May 31st post.

Sep 05 2005

I'd like to give each user the ability to edit their own Profiles page without being able to change those of other users. I could do this by setting the edit_page permissions in each user, but is there a way to set it for LoggedInUser that would automatically grant the permissions for the proper username? -- JBJ

Aug 25 2005

When using beta54 and .63, group names that are open (unsecured, or GuestUser with read_group-Name privileges) a group `URL without the name of the page requires login, but explicit page names do not (using nice URLs with .htaccess.) Even being logged in with read and write privileges for the group `URL is insufficient - an administrative login is required to avoid the "Insufficient privileges to perform action." error.

For example:
http://www.bucketworks.org/Theatre and
http://www.bucketworks.org/Theatre/HomePage

Aug 7, 2005

After an upgrade to pmwiki beta51 (and necessarily 0.63) I remarked that the markup (:loginform:) is resolved in edit form aswell.
If you edit, you have to delete the text string an replace it with (:loginform:) again :-)
-PatrickOgay

Aug 3, 2005

Patrick, I believe the reason is because (and this is a guess) that under php safe mode, you can't directly assign values to a $_POST[''] variable between two different scripts. Again, this is unverified, but it's my best guess.

-tparlin

 ***

Jul 31, 2005

There is a problems with a newer pmwiki (like beta51) and userauth 0.63 (I had to upgrade).
Users can log in, but when a site is password or edit protected, the password entry isn't accepted anymore.
Theron Parlins solution from the mailinglist:

userauth.php uses wiki_pw to receive password and assigns it to authpw befor calling $DefaultAuthFunction (usually PmWikiAuth).
Changements: (use of authpw directly instead of intermediate wiki_pw)

line 123
CheckPmWikiPassword( $_REQUEST['authpw'], $level, $pagename );

line 229
# $_POST['authpw'] = $page_passwd; is assiged already, now

line 327
in function GetWikiPasswordForm($pagename)
<td><input name='authpw' class='userauthinput' ...

Actually I don't know, why this changement is necessary, but my installation works again...
PatrickOgay

Jun 16, 2005

"Problems loging in, or creating the .htpassword file"

i installed it and get the password dialog, but there isnt a file in /local. So I didnt can get thru the password dialog - so its a little bit frustrating, its seems that there is a hidden passwort file?

May 31, 2005

Problem with password change.

I installed userauth (works fine) and also the password change script. When I try to change the password, I get the form to change the pass for the page, not the user. Any ideas?

C: I have faced the same problem. I've checked the sources and found that there are 2 methods for authentication in userauth.php: CheckUserAuthPassword(...) and UserAuth(...).

CheckUserAuthPassword(...) checks username/password and then determines if username has the specified action and whether it is overridden by another user with a higher level of privilege.

UserAuth(...) uses CheckUserAuthPassword(...) and in addition checks whether the user rights can be applied to the page in question or not (checks password for page with the standard PmWiki authorisation)

The point is that the latter method is used by userauth-pwchange.php even though no PmWiki page is changed. As far as I can see things .htpasswd is not protected by PmWiki authorisation and the check is performed on the page you use in your link for ?action=pwchange anyway (which is not changed in the course of events). So I've replaced

   if( UserAuth($pagename, 'pwchange') )

with

   if( CheckUserAuthPassword( $UserInstanceVars->GetInstanceUserName(),
   $UserInstanceVars->GetInstancePassword(),
   'pwchange', $pagename, false ) )

in function HandlePasswordChange($pagename) in userauth-pwchange.php and everything works fine.

Maybe I've missed something, so please correct me if I'm wrong. -- tri

If you follow the above recommendation, remember to add $UserInstanceVars to the global section of HandlePasswordChange -- JBJ

Jun 05, 2005

I uses pmwiki-2.0.beta37 (evolver + cms + userauth) and I found some other behaviour:

• the pwchange-button disappeared for all loggedin user -> the workaround above helped me out.
• I allowed editing of the WikiSandbox with edit_page-WikiSandbox for guests, this didn't work anymore. Any hints ?
  I changed the entry to edit_page-Main.WikiSandbox and the Edit-Button is now visible and useable. --Henry
• I don't understand the difference between the xxx_all and xxx directive ? The ability of read means to read all pages, same as read_all ?
  I read the discussion below, but this didn't work for me. I defined User1 to edit and User2 to edit, edit-group_Intern, assuming, that only User2 is able to edit the Intern group, but also User1 can do. Any idea, how to trace or fix it ?
  I apologize my mistake, I swapped _ and - in the abilities. Now I changed that to the correct values and it worked fine for me.
  I think, this is also a chance to provide a deny function. I will give the GuestUser the ability to read (all groups). The pages that shouldn't read by everyone will be allowed explicitly (read_group-Group or read_page-Group.Page) to special users. If there are only a small number of protected groups (or pages), this will save many definitions.
  We should sort this page in a reverse time order - with the newest entries at the top.

Henry June 05, 2005, at 10:54 AM

Feb 10, 2005

I can't seem to get it to work even though I've been tinkering with it for a few hours. I got this error message when I try to load my wiki site:

 Notice: userauth htpasswd file does not exist! in
      /home/jdoe/public_html/wiki/local/userauth/HtPasswd.php on line 44

I'm sure there's some basic, fundamental error somewhere that I've committed, but I'm spent. I don't know what I'm doing wrong. --JDoe

First guess... Do you actually have the .htpasswd file? Is there a permissions problem preventing the creation of it? It's supposed to be created in the local/ directory, where userauth.php lives, and you'll need to give your web server access to this directory to autocreate it, or use the one that comes in the installation tarball. --TBBle

I have the .htpasswd file in the local/ directory (the .htpasswd file that came with userauth). I'm trying it out on my uni's webserver which is kinda sucky. I suspect it's the server settings then. I'll try to chmod the local/ directory to 755 or 777 and then try it again later (as the server is down now, sucky). Thanks. Will be posting an update as soon as I try it. --JDoe

I had the same problem, so I show file path:

   if(!file_exists($htpasswd_file)) {
     /*pog: name/location */
     trigger_error("userauth htpasswd file does not exist: |$htpasswd_file|");
   }

and corrected my case in config.php like this:

   $HtPasswdFile = '/home/httpd/vhosts/ddy.ch/httpdocs/pm/pmwiki-2.0.beta14/local/.htpasswd';

(Probably you can use generic $HtPasswdFile = "$FarmD/local/.htpasswd" ) --pog

Feb 13, 2005

Markup Proposal, wanted to include a nice Login/Logout button within my wiki so I hacked up the following:

  ## (:userauth:)
  Markup('userauth','inline',"/

-- Gena01

1. The problem with ending up on the login page usually only happens when you try to login and accidentally type your password wrong on the first attempt. Then on the second attempt you are redirected back to the last page you were at, which happens to be the login page. But some sort of redirection would be a good idea for me to implement.
2. I think the CMSLike plugin might help solve some of your issues here. It can be used to only show actions that the current user is allowed perform. I will look into a providing a way to redirect users to specific group pages. This ability might come in the form of an additional plugin. I don't want to pollute the core of UserAuth too much.
3. Do you mean that you want to have some help text that describes possible abilities strings? I think adding such help text would be very useful! I thought at first about putting a drop down box, but there are so many possible ability combinations using group based abilities that such a drop down box would be very long.
4. Restricting access to certain pages can easily be added, but I am not sure how hard adding Category restrictions would be.

Thanks for the comments, I will look into some of this for version 0.6 -- JamesMcDuffie

Mar 8, 2005

I've got everything working, except I get the following error when I try to logout:

Too many redirects occurred trying to open “http://www.compratech.com/srmwiki/index.php?n=Main.LoginPage”. This might occur if you open a page that is redirected to open another page which then is redirected to open the original page.

I did everything as listed in the instructions and I am using the 'lean' skin. Any ideas?

-- kaptaink

I thought I had eliminated the possibility of infinite redirection, I guess I was wrong. My guess is that you did not give the guest user any permissions at all. Therefore, when logging out you are being redirected to an error message which it seems can not be displayed because of permission problems and is hence redirecting to an error page. In version 0.5 I specifically tried to make it such that error messages would not even check for permissions when being displayed. Which version of UserAuth are you using? If you are not using 0.5 then try upgrading. But I will also try to look into this possibly problem. -- JamesMcDuffie

Mar 11, 2005

I feel like I set everything up as directed, however, when I enter a user name and password, the login page just redisplays.

Any ideas?

-- Patrick

Which version of UserAuth are you using? In version 0.5 I added a mechanism that would display that the username/password is incorrect if authentification of the password failed. If you are using version 0.5 and are still seeing this message then there must be some other issue other than incorrect passwords. Did you make sure you used crypt correctly for encrypting the passwords? -- JamesMcDuffie

Mar 12, 2005

Hello again ! Since version 0.6 is on the way, it would be nice to do a bit of i18n on the login forms, by using "Username:" type of messages instead of just "Username:", so it can work with XLPage.

In GetUserLoginForm():

 
 $[Login to] $WikiTitle
 $[Username]:
 $[Password]:
 value='$[Login]'
 $[Logged in as]:
 ?action=logout\">$[Logout]</a>
 

In GetWikiPasswordForm():

 
 $[Enter password for] $pagename
 $[Password]:
 value='$[Login]'
 

The other messages can be customized in local/config.php. I think I've not forgotten any,... unless I have ;)

By the way, I've complemented your UserAuth plugin with one that I made in order to display only the relevant actions in the menus, depending on the user privileges. It's called CMSLike, and I've put it in the cookbook.

Cheers -- DidierLebrun

Thanks for the idea, it is something I will try to put into 0.6. I looked over your CMSLike plugin and I like it! The ability to easily implement things like this by utilizing what others have done is what makes PmWiki so cool! -- JamesMcDuffie

Mar 12, 2005

I just released UserAuth version 0.6, it has lots of fixes and improvements. Note that I changed the markup for the login page to be more consistent with the other PmWiki markup. Sorry if this causes you any inconvenience. -- JamesMcDuffie

Also I just released the skin I use for my site, EvolverSkin. Look over this skin to see how I have integrated both UserAuth and CMSLike functionality. -- JamesMcDuffie

The $IsUserLoggedIn variable was actually being set incorrectly in version 0.5. I forgot to mention that in the change log I originally posted, but now this change is posted.

You can actually put the code you have in 2) above inside your config.php as long as it occurs after userauth.php is loaded. The $UserInfoObj will be in the global namespace and hence accessible.

-- JamesMcDuffie

Mar 14, 2005

Hi ! There is a small problem with the $_SESSION['previous_page'] not being set properly in some cases in HandleLogin(). Apparently, it is properly set only when you use a login page, but not with the embedded one. Here is the fix I've found:

 
 ...
 } else {
 + $_SESSION['previous_page'] = $pagename;
   PrintEmbeddedPage( $pagename, GetUserLoginForm(false) );
 }
 

-- DidierLebrun

Thanks for finding this bug. I missed this issue because I always use the login form on a wiki page instead of the fall back embedded one. The fix has been released in version 0.61. -- JamesMcDuffie

Apr 09, 2005

Hi, I try to use userauth_0.62 with userauth-admintool and found an URL problem. I use $EnablePathInfo = 1 to get clearer URLs and I have to use wiki.php in the URL, so the complete string is http://www.gilgamesch.info/wiki.php/Main/HomePage?action=admin to launch the admintool. Now, the tooling presents the further URLs without the wiki.php, resulting in a HTTP 404 error. I changed the php-script

 
 # $AdminToolMainUrl = $_SERVER['PHP_SELF'] . "?action=" . $AdminToolAction;
 $AdminToolMainUrl = $_SERVER['SCRIPT_URL'] . "?action=" . $AdminToolAction;
 

and this works fine for me.

-- Henry

Thanks for the fix. This is probably how the URL should be constructed anyways. I will include this fix in a future update. -- JamesMcDuffie

April 13 2005

I get the following error:

Fatal error: Call to undefined function BasicAuth() in C:\Program Files\Apache Group\Apache2\htdocs\pmwiki\cookbook\userauth.php on line 436

I can't seem to find BasicAuth anywere in pmwiki where should it be?

I'm using version pmwiki-2.0.beta29 and UserAuth0.62

    function BasicAuth($pagename, $level, $prompt=true) {
      PmWikiAuth($pagename, $level, $prompt);
    }

--Pm

Thank you Pm, that (the function) gets me somewhere, but now I just get a message: Enter password for Justin.JustinsPage

I don't think this is right as I think I should get asked for a user name. Also the password I have set in my .htpasswd doesn't work. I'm running this on Windows XP using Apache as a test ground. It'll be on Unix when I upload it. Does anyone have any other ideas? Thanks,

Justin (justin@cherryleaf.com)

A quick update, I get the same problem on Unix. Thank you for all your help so far

Thank you very much! That seems to have done it.

Justin

April 14 2005

Hi!

nice stuff but I've a little problem. On my MDK 10.0 running

• Apache-AdvancedExtranetServer/2.0.48
• PHP 4.3.4
• pmwiki-2.0.beta26
• userauth-0.62

everything works fine.

On an identical PmWiki-Installation with userauth running on my Debian Woody

• Apache/1.3.26
• PHP 4.1.2

I never can logout. Once loged in, I've to close the browser to log out. Any hints?

TIA Chris

update

I upgraded to Apache/1.3.33 and PHP 4.3.10-10 (from a Debian testing apt-sourcelist). Now it works perfect TNX :) Chris

Apr 22, 2005

Hi, I set up a Wiki (Evolver-skin) for a closed group, but read all pages and edit a forum to all. I allowed edit_group-Forum for GuestUser, but all guests weren't allow to view the pages, but editing (and Previes) is possible. If I also explicitly allow read_group-Forum, everything is fine. In my opinion, edit permission should include read permission. Is it possible to change userauth to that behavior or missed I something ?

Thanks for this great contribution. --Henry

Well technically this would be correct, but maybe there is some situation where people would want guest to have edting abilities without reading. Maybe someone would want to use PmWiki for the result of a page submission or as part of some other application were others should not view the page. -- JamesMcDuffie

I'm also using Evolver + userauth + cmslike. Things seem to work except I can't give the guest user read access. Unless I'm logged in, every page has no content but just the login form I have GuestUser::read_all in my .htpasswd file. If I log in, things work fine.

Anybody got a tip for allowing read access for guest users?

Thanks, -Tristan

Problem with pmwiki-2.0.35?: I don't know the technical backgrounds, but due to the changes in pmwiki, userauth seems not to be working with that version .35 of pmwiki anymore - I get: "Fatal error: Call to undefined function BasicAuth() in ....userauth.php on line 436"
This very sad, because I am using this wiki with the user-management as a CMS.
Peter April 25, 2005, at 07:46 AM

Indeed ! The BasicAuth() function in PmWiki has been renamed PmWikiAuth(), so BasicAuth() calls in UserAuth should be replaced with PmWikiAuth() ones. At first glance, this little fix seems to be sufficient, but I haven't tested it thoroughly enough to tell whether it solves the problem completly or there are other unforeseen consequences. DidierLebrun

Jepp! It seems to be working all fine. I have replaced all appearances of 'BasicAuth' trough 'PmWikiAuth' - no further problems so far. Thanks a lot!
Peter April 27, 2005, at 03:06 AM

April 26. 2005

I'm having trouble with UserAuth after migrating to another server. I'm unable to log out and occasionally (I can't seem to tell when) makes my browser generate a redirection limit exceeded error. The copy is identical to the one running on the original server, the only difference is that the new server runs php 4.2.2 instead of php 4.3.10. ANY ideas what might cause this or how to go about to fix this?

I can provide you with the address for my wiki, an account and action=diag, if you think you can help.

Update: Adding destroy_session() to HandleLogout seemed to do the trick.

May 2. 2005

I'm having some problems with UserAuth (who hasn't?) i seem to be unable to login and can't figure out the cause. I believe it may be due to something odd on the sourceforge servers. right now i'm unable to log in and it continiously says that its been provided the wrong username and/or password. I'm not sure where to go from here. i can provide the address for the wiki easily as once i get this setup i won't be worried about spammers and such.

Also i am now using PmWiki-2.0-beta36, with UserAuth-0.62, the site is at http://denonline.sourceforge.net/ i've got a "guest" account setup with the same thing as the password. (guest:guest).

May 4, 2005

What would be nice is a "read_not-{$Group}" that blocks groups. Sort of "allow all, deny private" sort of thing. Or "deny_group={$Group}" BenWilson

• Or, how about 'deny-{$Group}'? Anybody?

May 5, 2005

UserAuth does not support the (:if auth ... :) conditional, this would be very useful if it did, or if its documented to use another method (:if userauth ... :) See examples at ConditionalMarkup.

-- Simcop2387

May 5, 2005

I'm not sure if this is correct place to ask questions, but I'm in the process of trying to set up pmwiki authorization. I've followed the instructions thus far and everything went according to plan, but I've run into the following error.

Fatal error: Call to undefined function: basicauth() in /home/brian/public_html/wiki/cookbook/userauth.php on line 436

Any ideas why it can't find this funtion?

Thanks, Brian Mitchell

Should be fixed in ver 0.63 -- JamesMcDuffie

May 14, 2005

Released version 0.63 which fixes the BasicAuth problem and includes the session_destroy fix. Hope this helps people out. -- JamesMcDuffie

May 23 2005

Sorry if this is not the right place to ask this. I installed UserAuth(v0.63 on pmwiki beta36) and happened to have default passwords specified in local/config.php for admin, edit, upload capabilites. I had to remove the settings for edit and explicitly specify crypt('nopass') for both the upload and pwchange capabilities to make things work for an ordinary user who had read,edit,upload capabilities in the .htpasswd file.

I may have worked around this issue by removing the first test in userauth.php that tries to pass the User's password to PmWikiAuth, in case it is the same as the pmwiki password. The problem I see is that the $authpw array in PmWikiAuth is always set by the first test (which I removed), so it would never add the posted password sent in $_POST['authpw'] to the authpw array. This is because the retrieval of the password from $_POST['authpw'] occurs inside an "if" statement that checks the existence of the array $authpw. Sorry, as I am way out of my depth, so my diagnosis may be far off the mark. Thanks to anyone who can help me with some real expertise on this problem.

In any case, does anyone ever use both types of authentication mixed together, or is it normal to only use one or the other?

Again, sorry if this is the wrong place for the above question.

Thanks, BillWraith

I have used both UserAuth and PmWiki passwords together. However, I did not set any passowords in the config.php file. Instead I used page or group attributes PmWiki passwords. -- JamesMcDuffie

May 23 2005

Hello,

I was wondering if there is a way to keep track of User logins. Like a log file that says when a user logged in.

Thanks, AlexRamon

I am sure that it would not be to hard to write logins to a file with a date/time stamp. That might show up in a the next release, whenever I get around to working on it. But if someone else beats me to the implementation, I would be happy to include the changes. -- JamesMcDuffie

Theron Parlin? found a bug:

I found a bug in the userauth recipe for pmwiki. Everything worked until I tried to password protect a page. I would enter my password but it kept returning the password prompt to me, never accepting my password.

The problem is in userauth.php in the CheckPmWikiPassword function, there is a line that reads:

$_POST['authpw'] = $page_passwd;

It looks like the author was trying to pass the page password to the PmWikiAuth function in pmwiki.php. This won't work in some environments (namely php safe mode, which I'm running). I fixed it by changing all references of "wiki_pw" to "authpw" in userauth.php and removed the line above from the CheckPmWikiPassword function and all was well.

This fix will be in a future release --JamesMcDuffie

Feb 8, 2006

Hi! I'm trying to setup UserAuth with CMSLike and add finctionality of CommentBox. Wiki pages are readable to any one but editable only for admins. CommentBox has some code do bypass PmWikiAuth but it unfortunately does't work with UserAuth. As a result guest user trying to add comment is asked to login.

Code fragment from commnetboxstyled.php:

function HandleCommentPost($pagename) {
  global $_POST,$JournalPattern,$DiaryPattern;
  global $AuthFunction, $oAuthFunction,$Auth, $EnableBypassAuth;
  if (!@$_POST['post']) Redirect($pagename);
  SDV($AuthFunction,'PmWikiAuth');
  $oAuthFunction = $AuthFunction;
  $AuthFunction = 'BypassAuth';
  if (preg_match($JournalPattern,$pagename)) HandleJournalPost($pagename);
  elseif (preg_match($DiaryPattern,$pagename)) HandleDiaryPost($pagename);
  else HandleMessagePost($pagename);
  HandleEdit($pagename);
  exit;
}

Any ideas?