[pmwiki-users] UserAdmin cookbook

Alex alexware at szokesandor.hu
Sat Feb 20 16:51:31 CST 2016


Dear Peter, 

I have just found the reason, why it behaves like I
have described. I have a Cookbook: cmsmode. I had to debug through
pmwiki to find it.... :( 

It blocks most actions, including UserAdmin
actions as well, especially for an anonymous user (if logged no
blocking). It is necessary to add the needed actions to the white list
of actions. In config.php, I had to add the following:

$CMSAllowedActions[] = 'user';
$CMSAllowedActions[] =
$CMSAllowedActions[] = 'user/unlock';
$pagename =

anonymous user can do reset password and unlock as it is expected.


2016-02-19 06:31 időpontban alexware at szokesandor.hu ezt írta:

> Dear Peter, 
> 1. anonymous - the user who visits my site, has no
password, cannot log in without any password.
> Is it a wrong
> 2. Initially I also installed
"Cookbook.UserAdminTemplates" and tried to modify the apperance of the
main menu as it is written on the hompage. I figured out, that I am
unable to modify, finally I looked into the code. There is a quite clean
definition, that if there is a templaet exists, than construction of the
main menu is skipped. (causing showing the same menu to both admin,
users, visitors [currently has no menu at all]) 
> 3. In the
"Cookbook.UserAdminTemplates" template you missed out the e-mail filed.
Therefore, the form that is currently defined cannot be used. This
caused me some disturbance. 
> On the AuthUser page, for each user an
e-mail fieeld need to defined (I have tested this function with e-mail
fields defined, since I cannot expect good behaviour from in incomplete
set-up), I think this e-mail could also be used - without one explicitly
enter in on the form - to send the e-mail. Is not it? 
> I hope that
the explanation is better know. If you need more details I could also
share more config settigns. 
> Alex 
> 2016-02-18 11:24 időpontban
Peter Bowers ezt írta: 
>> On Tue, Feb 16, 2016 at 10:02 PM, Alex
<alexware at szokesandor.hu [1]> wrote:
>>> I found some issues that I
would like to share:
>>> - I do not understand how the recipe is
activated. I am using
>>> useradmin-authuser.php
>>> I modified
useradmin-core.php to echo debug message upon activation:
############################# start of cut
$RecipeInfo['UserAdmin']['Version'] = '2015-09-20';
>>> if
(strncmp($action, 'user', 4) == 0)
>>> SDV($HandleActions[$action],
>>> function HandleUserAdmin($pagename, $auth =
'read') {
>>> global $action, $UserAdmin;
>>> echo "DEBUG: 

>>> action: ".print_r($action,true)."
>>> n";
SDV($UserAdmin->pagename, $pagename);
>>> #############################
end of cut
>>> When an anonymous user fires "action=user", it does not
display the
>>> debug message. It also cause that an anonymous user
cannot access
>>> resetpassword or unlock form! How can this happen? Am
I miss something?
>> It has been quite some time since I have worked
on this recipe. By "anonymous user" do you mean users who have logged in
with a password but without a username? If so I will have to do some
testing - I don't use that particular capability often and so it is
likely the recipe is under-tested for these. 
>>> - There is a
paragraph "Configuring the main menu for UserAdmin options"
>>> There is
also a page for template definitions: Cookbook.UserAdminTemplates

>>> I thought, that they are both needed at start, but found that there
>>> some inconsistency issues with the forms:
>>> 1. There is an
excellent mechanism, which menu item to display, to what
>>> type of
user. If there is a form defined, it totally breaks this
>>> definition.
Only one template can be used. :(
>> Can you explain your concern in
more detail? For instance, "If I have X template defined then Y
functionality does not work". I am quite certain that I have tested
systems both WITH and WITHOUT templates defined as well as combinations
of the above, but clearly there is some edge condition that I have
>> 2. When using the forms e.g
>>> /> address also.
Therefore, it is not working with this "default" template.
>>> I have
spent several minutes to figure it out. 
>>> Email is a required field
since we use it in so many different areas to confirm identity (i.e., a
password reset is impossible without email using current functionality).
Are yo
>> difficulty occurred during the migration period when you had
existing users defined without the email address being available? 


[1] mailto:alexware at szokesandor.hu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20160220/f092f4b3/attachment.html>

More information about the pmwiki-users mailing list