UserAdmin-Talk

Summary: Talk Page for UserAdmin.

Users: (View ? / Edit ?)

Please leave new comments at the top of the page (but below this line).

PHP 8 compatibility

The date of this entry is 2024-10-24. My PHP version is 8.3. I get an error

causes:

useradmin-core.php line 672
https://www.php.net/manual/en/function.crypt.php: The parameter salt is no longer optional.

proposed solution:

specify a $UserAdminSalt variable in the local/config.php
use it as salt parameter in the useradmin-core.php line 672
update the installation part of the documentation

There is a core function pmcrypt() that can be used instead of crypt() for recent PHP versions. I don't use the UserAdmin recipe, someone who does should take over the maintenance. --Petko October 24, 2024, at 12:28 PM

Status?

Is this recipe still being maintained? The testing site throws errors and is not functional

||Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /homepages/39/d252297167/htdocs/pmwiki/cookbook/useradmin-core.php on line 1177
||Warning: Cannot modify header information - headers already sent by (output started at /homepages/39/d252297167/htdocs/pmwiki/cookbook/useradmin-core.php:1177) in /homepages/39/d252297167/htdocs/pmwiki/pmwiki.php on line 1258

I'm going to set up a wiki soon where this functionality would be greatly appreciated. Thanks! -- Mierk March 16, 2018

Captcha support

Does this recipe pay attention to the results of captcha? I use captcha elsewhere on my website, so I put the following in a UserAdminTemplates form after the password input line:

|| (:if !authid:) Enter value: {$Captcha}||(:input captcha:) ||(:else:)|| ||(:ifend:)

Result: The form created the new user despite the captcha code not being entered. -- RandyB September 30, 2016, at 09:47 PM

"Captcha" is a generic name for many different possible technical methods, each of which will be implemented with very different code behind the scenes. Displaying a captcha field on a form is one relatively minor detail in terms of implementing Captcha. Currently UserAdmin does not support Captcha. Peter Bowers October 01, 2016, at 07:09 AM

Feature request: support the Cookbook:Captcha recipe. -- RandyB October 01, 2016, at 09:54 AM

Variables available in custom templates?

If I am making a custom template, I can specify $username, $link, and $WikiTitle. Is there a way to specify the website's URL? For example, the built-in template for resetpasswd generates an email that says "please contact the site admin at..." followed by a link. How would I recreate that in my custom template using a variable? -- RandyB September 17, 2016, at 09:51 PM

I'm a little surprised that any variables work in custom templates. I would suggest just typing in what you want if you want to use templates (i.e., without variables). If you want variables then modify the appropriate value in the XLSDV() within your config.php - check the 2 keys that end with "email_body" and use the appropriate double-quotes or here-docs or .-operator to make sure that the variables you want to be used are visible. Peter Bowers September 18, 2016, at 11:02 AM

I don't know how to make a variable visible in a template.

If my UserAdminTemplates page contains a UAresetpasswd_email_body template with text like "Dear $username at $WikiTitle", I get the variable replacement. I think that's because those two variables are declared in or else declared "global" in useradmin-core.php. However, I don't know how to make visible $myvariable within the template, without changing useradmin-core.php. I do know how to use XLSDV to redefine the entire value of UAresetpasswd_email_body in my config.php, and in that way use variables, but I'd rather make a variable that I can just insert into a template on the templates page ("Dear $myvariable"), so I can easily tweak my wording on a wikipage rather than having to edit the config.php file. Can this be done solely through config.php and UserAdminTemplates? If so, how? -- RandyB September 18, 2016, at 06:20 PM

The code for allowing variables is a little complex and to make it helpful any changes I make should really allow PVs. If I get a few minutes I will send you a draft to test. Peter Bowers September 19, 2016, at 03:55 AM

Preventing selected users from managing their own accounts

Is it possible to prevent a user (or better yet, a group of users) from managing their own accounts? Let's say I have a SharedAccount whose password and email address should never be changed by the people who log in using that account. Is there a way to configure UserAdmin to prevent them from making changes? Unfortunately, UserAdmin must be loaded before AuthUser. Could I set revise the $UserAdminActions value after loading AuthUser, or would that cause problems? -- RandyB September 12, 2016, at 11:51 PM

I took a quick look at the source and I'm pretty sure you can set $UserAdminActions after loading AuthUser. Try it and if you run into problems, let me know... Peter Bowers September 13, 2016, at 01:44 PM

By setting up $UserAdminActions after loading AuthUser, I can prevent the Edit option from appearing in the menu of available actions. However, by appending "?action=user/edit&username=SharedName" to the URL, the user could edit the account anyway. Can that be prevented somehow? -- RandyB September 13, 2016, at 04:02 PM

Fairly limited time to respond. Suggestions? Peter Bowers September 14, 2016, at 07:12 AM

Perhaps you could have a $UserAdminAuthorizedUsers configuration variable that contains a comma separated list of authorized users and groups. If defined, you could check each element to see if the current user has the specified id or belongs to the specified group before allowing any action. Alternatively, if there is something that useradmin needs (e.g. that the $UserAdminActions cannot be null) before it will do any action, the configuration file can test for the user id and set the value of $UserAdminActions accordingly. -- RandyB September 14, 2016, at 04:05 PM

Error due to preg_replace deprecated

Hi! I'm running with version 5.6.8 of php and pmwiki 2.2.78. and trying to use useradmin-core and useradmin-dbase but the error message is the following:

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead .../cookbook/useradmin-core.php on line 1014

Warning: Cannot modify header information - headers already sent by ...useradmin-core.php:1177 in ...pmwiki.php on line 1240

Is there an issue for these problems?

Jvamp February 27, 2016, at 09:46 AM

The problem doesn't exist on my copy at home, so it appears I am behind in my release cycle. I will try to get a release in the next couple days. Peter Bowers February 29, 2016, at 07:52 AM

I never came back to update this, but this problem is solved AFAIK with a release which occurred long after "the next couple days" but "better late than never". Peter Bowers September 13, 2016, at 01:44 PM

Error message

I have an error message, if I try the ?action=user, for all options

Parse error: syntax error, unexpected '[' in /.../useradmin-core.php on line 1206

So, it doesn't work.

I think the hosting don't use php 5.5 but a previous version.

Benji February 19, 2016, at 02:55 AM

I thought that the capability of dereferencing arrays returned from functions (i.e., myfunc()[2]) was in 5.2, but apparently (as per http://php.net/manual/en/language.types.array.php#example-102) it didn't come in until PHP 5.4. I have updated the requirements for the recipe to require PHP 5.4. Peter Bowers February 20, 2016, at 02:43 AM

Authgroups in AuthUser version

(1) I tried the "reset password" function, to reset the password for a user who belonged to several groups. The form showed me much more than just fields related to resetting the password. Perhaps that can be fixed by custom forms. It also removed some information from my Site.AuthUser page. Perhaps that's because I already had a page in the normal AuthUser format. To allow people to transition to UserAdmin who didn't start with it, is it possible to preserve the old information?

The idea was that resetting password was a special case of editing a user profile and so the 2 pieces of functionality could be combined fairly painlessly. I'll think about separating them, but it'll probably be fairly low priority since there's not a lot of benefit to it. (I see lots of places around the 'net where passwords are reset/changed within the profile editing section.) Perhaps changing the wording on the menus would suffice?

To me the value of the Useradmin recipe is to relieve the admin of a large workload. The larger the number of accounts, the more useful the tool. If I can't allow a user to change his or her own password, email address, or similar personal information without also granting the user unlimited privileges such as the ability to add himself or herself to the list of admins, then my wiki can only include fully trusted users. Perhaps useradmin should allow the configurer to specify which information is obtained from and stored in a Profiles page, and which information comes from and is stored in AuthUser. Making it all or nothing, either/or, limits the recipe's usefulness.

Currently users can never change group membership - that is restricted only to admins. The things normal users can change are email, password, and custom fields such as real name or etc. Peter Bowers September 24, 2015, at 06:44 AM

Are you sure? When I am not logged in as an admin, I still see when I specify "?action=user/edit" checkboxes for all user groups including @admins. -- RandyB September 25, 2015, at 03:43 PM

But are they read-only or editable? The idea is that they can see but not change their group memberships. Peter Bowers September 26, 2015, at 12:53 AM

You are right - they are read-only. The labels aren't dimmed, so I assumed the checkboxes were editable.

Note: To be really useful, some authorization groups should be self-changeable, and other groups should not be. For example, the wiki might allow anyone to self-join @registrants or @brainstormCommittee, but not to self-join @admins or @paidSubscribers. (Actually @registrants should be automatically included in the Profiles template, so the user doesn't have to remember to check the box.) -- RandyB September 23, 2015, at 02:09 PM

Yes, I totally agree. I've played around with the idea of super-admins and per-group-admins and open-groups in order to facilitate this kind of thing. Unfortunately this type of thing is inherently core security type of issue and therefore not the type of thing I want to play fast and loose with. I'll continue to ruminate on it and meanwhile put this in the roadmap. Peter Bowers September 24, 2015, at 06:44 AM

Removing information from Site.AuthUser page is a significant problem and one I've tried hard to avoid. Is your site one that I can access so I can look at the diff output and see what was lost? Or can you give me more details? This is a high priority item and one I want to address quickly and well. The goal is that no existing information would be lost/changed from SiteAdmin.AuthUser. Peter Bowers September 23, 2015, at 02:35 AM

I had two lines of information per user (one for the password, and one for group memberships). Perhaps you assumed there would be just one line. I'll experiment with using useradmin from the start, to see if information still disappears. -- RandyB September 23, 2015, at 02:09 PM

(2) It seems you keep a list of members for each group. That's fine when the list is short. But if there are 1,000s of members per group, wouldn't it be better to have a list of the groups for each member? Then to add or delete a user manually you only need to add or delete the user's one line.

E.G.

Me: @writers,@admins

You: @writers,@admins,@developers

...and 1,000s of other lines, each of which can be more easily manually changed, added, or deleted

Instead of:

@writers: Me,You... and 1,000 other names

Each way of organizing may have its advantages depending on the website. Is it possible to allow the installer to decide which way to keep the information?

It's an interesting problem with perhaps no "best" answer. Allowing the administrator to choose gives flexibility, but I'm not sure how much benefit is added. The assumption is once you start using UserAdmin you will continue to use it and manual edits to SiteAdmin.AuthUser should almost disappear. Putting it on the roadmap is certainly possible, but it's probably going to be a low priority.

PHP 5.5 compatibility

I get this message: "Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in... useradmin-core.php on line 1014" -- RandyB September 22, 2015, at 02:26 PM

Good catch - I didn't realize that was in there. I will fix it asap. Meanwhile be aware that you have an older version (based on the line numbers) and need to update.

What versions are current? For useradmin-core.php I'm using "2015-09-20". For useradmin-authuser.php I'm using "2015-05-16". -- RandyB September 23, 2015, at 02:46 PM

Sorry, my bad. I found a *different* occurrence of the same bug at a different line number and assumed it was the same. So there are at least 2 occurrences of that php5.5 issue. The versions you described are exactly right. Peter Bowers September 24, 2015, at 06:44 AM

DBase setup instructions

September 8th 2015

As per the set up instructions I placed the MySQL information directly above the useradmin include; However, the script didn't work for me until I moved the useradmin include above the mysql settings.. I had thought to modify the directions myself, but thought I had better get a second opinion and make sure we are all on the same page before messing with it.

Installation instructions updated - I had forgotten the include_once(...) line entirely.Peter Bowers September 16, 2015, at 04:21 PM

Setting up Groupswith Dbase

Auguest-14-2015 How do you configure groups. I keep getting Not Authorized even though I'm logged in as SuperUser ~ Gerolkae

For UserAdmin->Dbase the "superuser" concept is synonymous with the idea of having admin privilege on the current page. Is that what you mean when you say you're logged in as SuperUser? When logged in as SuperUser can you edit pages that are locked with the site-wide password? Peter Bowers August 14, 2015, at 08:59 PM

By superuser I mean Site admin. The Error message was confusing. What happened was I added a group with out the @ prefix and it triggered UnAuthorized...

Second Note Dbase conflict with scripts/urlapprove.php action=approvesites gets grabbed by UserAdmin and shows action=user instead

Both of these issues are now fixed in my development copy, soon to be released.Peter Bowers September 16, 2015, at 04:17 PM

UPDATE: Released as of 9/20/2015. Peter Bowers September 24, 2015, at 09:10 AM

Gerolkae August-14-2015 8:53 pm

Authentication-Lite

21-Jul-2010 DaveG: I'm looking to emulate some [(approve links) edit diff] (and others, like Posterous) functionality in BlogIt, where an unauthenticated user subscribes to a blog-entry, and subsequently receives an email notification if other users comment.

The way this is implemented in WP is to combine the commenter email with a 'large' randomized string (let's call this the authstring), and use that set of parameters as an means to authenticate subsequent management of subscriptions. This way, the commenter does initially confirm the email address is active, and that they wish to receive email updates, but all subsequent management activities are performed using a link containing the email+authstring combination, and do not require the commenter to login.

This is not 100% secure, since in theory some one could guess the email+authstring combination, but is typically secure enough for this use-case, and reduces the burden on blog-commenters, since there is no password management -- simply retain the email containing the email+authstring combination.

Here's how I think the process works, and where I think UA might fit in:

Commenter decides to subscribe to a blog-entry, and enters an email address (usually clicks a checkmark as well).
UA: Generate a randomized authstring. (WP does a double md5 with a salt return md5(md5($this->settings['salt'] . $data));)
UA: Store email address, and authentication-target.
Somewhere an authentication-target url, or what is being subscribed/authenticated to needs to be stored. Note sure if this should be UA, but I suspect this is going to be needed by other users of UA. Implication is that a user may have more than one entry.
(UA): Store the authstring in a cookie.
Possibly leave this to calling recipes, use some other ID, not authstring
UA: Send out an email to the commenter. Email contains an 'approval url' which has parameters of email+authstring.
User receives email, and clicks the approval link.
UA: Regenerate an authstring based on email, and validate the url email+authstring parameters; set an approval timestamp (acts as an approved-flag). Forward user to the authentication-target.

Based on above, here's some functions that might be required:

List of all authentication-targets for an email address.

Looking at the UA code, it seems much (possibly all) of this is already part of UA, although at the moment it seems like the password component is required.

Profiles with AuthUserDbase

I'm using AuthUserDbase but also interested in collecting profile info on users, whether through the database or in conjunction with a profile page approach. Any thoughts on how these might work together? I left a related message on AuthUserDbase-Talk.

~bb June 30, 2010

(previous comments deleted.) There is now a useradmin-dbase. Peter Bowers May 18, 2015, at 12:23 PM

Required email capabilities?

It's not clear to me if the web site needs to have email capabilities. I think it does, but I'm not sure. R D Jones July 02, 2011, at 05:53 PM

When a new user auto-registers they are required to confirm their email by a link sent to their email address. So, yes, the server has to have email capabilities. Peter Bowers May 04, 2015, at 09:56 AM

Changes required to work with current versions of PmWiki / PHP8.

I am trying to get this to work with a current PmWiki-Version and it seems to be necessary to replace all occurrences of "crypt" with "pmcrypt" for it to work at all. Since I couldn't produce a fully working configuration I so far didn't try to du whatever the equivalent of a pull request is round here.

RalfB, Feb 18, 2024

Security implications

Editing $UserAdminActions does change the visibly fur the user-actions. However this doesn't really provide security, as the links can be manually constructed and no checks seem to take place.

For my site I would like to allow users to reset/change their passwords, but I don't want to enable auto-signup. Right now, I am trying to adapt the script to honor the visibility before executing the action. I suppose ValidateInput would be a good starting point and the computation of the available actions should be refactored out of Menu.

So far, my lack of PHP-skills makes me fail on the refactoring part, but I will keep trying. Help is welcome, however.

RalfB, Feb 18, 2024

Talk page for the UserAdmin recipe (users ?).