- U s e r B a s e d A u t h o r i z a t i o n / L o g i n S y s t e m -
Now Integrated with the PMWiki Password/Login
Self-Registered with Email Verification using MySQL
This is a New, Heavily Updated, Version of MyDBLogin
Questions answered by this recipe
- Can I implement individual and user-class Wiki Group-level and Page-level access control of my wiki?
- Can I use a MySQL database to manage the User/Login information?
- Can I add a white-list to limit self-registration to pre-selected users? (or not if I don't want to...)
- Can (whitelisted) users self-register and change their own passwords?
- Can (whitelisted) users use email-verification to validate themselves during registration?
- Can (whitelisted) users handle forgotten passwords themselves with an email reset?
- Can I create and use user-groups to limit specific access to wiki-Groups or Pages?
- Can I use User-Classes(Groups) to Access or Redirect to specific pages?
And the answer of course is:
All sections are optional, you can remove those that do not apply to your recipe, and add new ones.
MyDBLogin-PMW integrates with PMWiki's default password system, adding a User-Level layer for Group-level and Page-level access-control. Each user only knows their own password but is granted Admin/Edit/Read rights using hidden PMWiki passwords. User-logins and user-passwords are managed with a MySQL database. Registration and changes are automated, and validated via email.
This is the next generation of the MyDBLogin recipe.
But it is so different from the earlier one, I gave it a new Cookbook page, however, I still think of it as just 'MyDBLogin' - as you will see through-out the code, and this page.
I needed a tool to limit access to certain wiki pages for members of our Scout Troop, but I did not want to manage everyone's password using the Admin level of PMWiki (c.f. AuthUser).
In other words I wanted users to be able to register their own Username and Password in order to have access to certain pages, but limit this to a "white-list" of acceptable users/emails. Even better if I could display pages and images of the Wiki according to different User-Groups: for parents, for Scouts, or for each scout-patrol; but I did not want to have to set/change everyone's passwords manually as members come and go, and change roles within the organization.
So, I put some things I knew how to use together and created MyDBLogin, however, although the first version served my purpose, it was clunky and did not integrate with the PMWiki login tools.
A little more than a year later, I now have a much improved version which integrates with the PMWiki login Passwords, and is a self-contained recipe - making it a lot easier to implement, and more flexible.
It does have a number of parts, but I have documented things carefully and I have tried to keep all user-settings organized into only two places:
- the code for your /local/config.php file and
- the settings in my _setup.php file ( which is more commentary than it is code, to help you customize to you needs.)
If you have a little experience with PMWiki, MySQL and with working with a server,
and you take the time to read the instructions, you should be able to handle using MyDBLogin easily.
- Keep it simple to start, but once you get it going, there is a lot you can do with it!
Maintaining an individually refined identity based access tool requires a lot of work - So I have avoided that.
PMWiki's built in Password system is very simple but means if you need to change a password you need to get it to everyone who needs access - that can be a headache.
The built-in AuthUser system, requires more hands-on, inside-the-system maintenance than I wanted, so... MyDBLogin was born.
What MyDBLogin does best:
MyDBLogin balances simplicity/control/user-management:
- In a Group with a small number of Classes of Users who need private access to different Wiki-Groups - This works Well!
- We use the simplicity of the built-in PMWiki access Passwords (Admin,Edit,Read),
- PMWiki permissions are managed in a single MySQL Table for ease of editing and management.
- Self-registration, limited to a "White-List" of acceptable users prevents unauthorized use. (Optional)
- Group or Page access (Read) is granted using MyDBLogin, Edit/Admin is handled by PMWiki using the (Hidden) Password retrieved by MyDBLogin.
- In the Keep-It-Simple philosophy, each individual has only one PMWiki Authorization level (Admin/Edit/Read).
- However, using the turnstile.template.php, each User-Group or as I call them User-Class can be granted/denied access to any wiki-group or page.
- A User-Class with only one member means we can handle access by individuals
- User information is all kept in php variables or passed using $_SESSION variables
What we Don't Do well:
- Currently MyDBLogin does not allow page-based shifting of Edit/Admin rights.
- Not exposed, but technically available in the code, is use of the User-Name / User-Email within Wiki-Pages.
- Each User has only one Class, so to manage multiple Class Membership you would need an additional User-Class with rights of the sub-Classes.
- Each Access permission is handled with a separate file for each Wiki-Group or individual Page, there is no provision for batching.
Basics of What MyDBLogin Does:
Once everything is setup, you will have a single PMWiki page that handles user Registration, Login, Password Reset, and Forgotten Passwords.
Users can self-register, providing their email, a username and a password.
If you are using the White-List, only users you have pre-approved will be allowed to register.
The registration must be validated by responding to an email sent automatically as part of the MyDBLogin registration process.
Once Validated, the user can login using the MyDBLogin page which will both allow MyDBLogin access and also log the user in with the assigned PMWiki password
-->by default that would be the 'Edit' password. The MyDBLogin user never sees the PMWiki password! So you can keep them or change them as often as you like by just editing your /local/config.php file and then the MyDBLogin MySQL table.
Users' PMWiki Authority-level can be changed from the single MySQL table, individually or in a batch.
Wiki-Group and Page access can be managed by simply copying and renaming the lock-out file to match the wiki-Group or Page you wish to control,
or by editing the file, you can manage user/group level access,
with a few code changes you can even limit access to or from individuals.
As a by-product, you now have a PHP file that recognizes user-access to a specific Group or Page, and allows you to create programmatic responses, based on the user, the user-group or the PMWiki authority level (Admin/Edit/Read).
Users can manage their own passwords even forgotten passwords, by using the email validation tool, so the Web-Administrator never needs to be involved with that task.
We have three working parts here: PMWiki, MySQL, and PHPMailer.
- Unzip the file somewhere you can edit things.
- You will need to edit the file named "/mydblogin/_setup.php" but otherwise everything is ready to copy to your server.
- The ~HowTo.txt file has full instructions and even MySQL Create scripts.
- Setup PHPMailer on your server. You may need to ask your hosting service for any special instructions.
- Setup a MySQL database and the table for Users, and one for the optional White-List. (Scripts are in the ~HowTo.txt file)
- I recommend testing these parts individually to be sure you have the right settings and passwords.
- Now we need a directory/folder on your server outside of the pmwiki installation for the MyDBLogin code.
- You obviously need a PMWiki installation, but now add a PMWiki Group to handle your logins I use "Turnstile"
- Now you need a MyDBLogin Wiki-page, I call mine "Turnstile/Validate"
so that looks something like
www.myexampledomain.org/pmwiki/pmwiki.php/Turnstile/ValidateThis page just needs one line of markup:
(:MyDBLogin https://www.myexampledomain.org/mydblogin/ :)Obviously edited to match your MyDBLogin path!
- Optionally add a Wiki-page to inform folks they need special authorization for access, say - "Turnstile/NeedAuth"
In addition to whatever message you want to share, be sure to add a link here to your "Turnstile/Validate" page!The choice of which page you direct unauthorized access to, is built into the Turnstile.Template.php file.
Once you get this far, you should be able to play around and see everything work for the login features.
To work with the actual Access-Control we move to Configuration:
You should now have a working MyDBLogin page.
You should be able to Register, Login, Change your Password, or trigger a Forgotten Password Change.
If not, go back to Installation.
This is the simple part.
The Turnstile.Template.php file you copied to the /local directory is in fact... a template! (What a surprise!)
If you make a copy and rename it to match a Group name, Access to that wiki Group is now controlled by MyDBLogin!
You don't even need to open the file!
But if you do, you will see you have the option to control access at the Authorization level (Admin/Edit/Read).
You will notice, MyDBLogin is not tied directly to those levels, you can create your own Classes (user-groups) to control access, but still granting Admin/Edit/Read rights.
By using the Group.Pagename option you can limit access to a single page!
E.g. copy Turnstile.Template.php and rename to Members.Directory.php and you limit access to that single page (.../pmwiki.php/Members/Directory) to MyDBLogin validated users, or even some sub-set of them.
The Next level of control comes with your MySQL table.
Using a tool like phpMyAdmin you can edit the MySQL user table to change user PMWiki access passwords, thus granting or removing Admin and Edit rights.
This is done by changing the user_pw field to match the PMWiki password that grants those rights (from your /local/config.php file.)
The user never sees this password, it is used "behind the scenes" to manage PMWiki rights.
Not part of this recipe, but with a simple C.R.U.D. interface you can even manage your users, via a wiki page, accessing the MySQL table!
Adding, Removing or changing permissions, while using MyDBLogin to limit access to that interface to the MyDBLogin authorized Website Managers.
That's on my ToDo: list...
Let me know if you want to help, or if you need the template for it.
The following strings can be translated in an XLPage:
To do / some day / maybe
Make using/bypassing the whitelist as simple as setting a Boolean flag.Done!
- Add stub-code in Turnstile.Template.php for individual user identification using Session Variables.
- Add code for the C.R.U.D. interface to manage the MySQL tables.
Auto-Refresh to see Logged-in status immediately.Done!
If you have future plans or wishes for this recipe.
Change log / Release notes
If the recipe has multiple releases, then release notes can be placed here. Note that it's often easier for people to work with "release dates" instead of "version numbers". Release date of MyDBLogin-PMW 2021-02-12
This is a Major revision of MyDBLogin so much so, that I created a new Recipe page.