Right now, an admin has to change passwords in AuthUser. Some people don't
want to tell the admin their password.
I am working on a membership site where members will log in and need edit
permissions to their own profile information (name, contact info, description,
etc.), can change their own passwords, are in a group @members so that
permissions can be doled out around the website, some members can be @admin (or
other permission group) privileged. And I'd like to avoid using a database.
I'm looking through PmWiki documentation, recipes, etc. So many recipes are
old, haven't been maintained in 4+ years, are not PHP5 (much less 5.5)
compatible, etc. I was trying to get .htpasswd files working, spent a whole
day on that, got it working -- but the recipe I was going to use to handle
password updating and group management is
http://www.pmwiki.org/wiki/Cookbook/HtpasswdForm -- and it's broken (and too
complicated for an easy fix). I put the (:command:) in the page, and the page
comes out blank when it should come up with password updating and group
permissions forms.
In all honesty, I love the simplicity of AuthUser. It would be lovely if
PmWiki finally got -- a little -- more sophisticated on user/password
management. Here's my thought on how it can be set up for users to edit their
own password:
Similar to SiteAdmin there could be a locked-down group, perhaps (to keep with
$BaseName tactics) "Profile-Data". This would be a PmWiki data page hidden
from the world. In it could be profile data (page $Name = username, crypt'd
password, email address, phone number, member expiration date, whatever...).
What I need:
I would like to be able to tell SiteAdmin/AuthUser to use
Profile-Data/{$username}$:passwd for username/password auth. So just like it
would grab a username/password from the SiteAdmin/AuthUser page, I want it to
grab the passwd: <encrypted password> from their Profile-Data page.
I also need a way to set group access attributes so that only id:{*$Name} (i.e.
the current wiki page name) could edit their own pages (plus admins of course).
That might be configurable already via local/Profiles.php
This I can probably do, although I'm rusty:
The user corresponding to the Profile, when logged in, can either directly edit
their Profile-Data page, or (when one has edit permissions) there can be a form
for updating their Profile-Data/$username data that saves data and the
encrypted password to the corresponding Profile-Data/$Name page (cf how PmForm
saves data to another page) while visiting their own Profile.
Then the only case in which an admin is needed is if a user forgets their
password, not if they just want to change it. This means admins can set an
initial password and the users can change their own password after their first
login.
Crisses_______________________________________________
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
