Questions answered by this recipe:
--First Release 2019-11-08 --
Can I protect certain pages and groups with a user-login system where users create and update their own passwords, using email verification to register?
Can I, at the same time, limit the users to only a preset list of authorized users, a "whitelist"?
Can I keep the login credentials for the user-session but protect all sensitive data using Server-Side Session variables?
Can users be given different levels of access, which can be changed easily?
Can I maintain my list using an online MYSQL database so I maintain the User-List and Credentials with embedded DB functions with my Wiki using other recipes?
All sections are optional, you can remove those that do not apply to your recipe, and add new ones.
MyDBLogin is a tool to provide user-managed, individual passwords that allow access to specific pmwiki Groups or individual pages. The self-registration process uses email verification and is limited to a whitelist of permitted emails - preventing registration by anyone but a specified group of individuals.
Having tried to work with the existing authorization methods in PMWiki I could not get a flexible system where users can register and set their own passwords; while at the same time limiting the users to an existing list of available emails.
My solution is more of a work-around than a fully pmwiki-integrated solution, but once set up, it is clean, flexible and easy to maintain.
The real-world description is that I have a website for our Scout troop and we want to have a directory with addresses, emails and phone numbers available online, but we need it to be secured by individual credentials, and only available to current members of the Troop. Thus MyDBLogin was born.
I am well aware many of the parts of this are available in existing code, and I would love to have the time and knowledge to build the flat-file handling code to use the AuthUser methods; however, using code I already had for other projects this got me going, and it will be more familiar to many in terms of modifying and maintaining, given the over-abundance of SQL database use out there.
The Big Drawback (although for some it might be seen as an advantage) is that it does not integrate with the existing password/login tools, so you may be requested to log-in twice in one session once to PMWiki and another time to MyDBLogin
The Big Picture:
This Recipe uses several "Outside The Wiki" solutions
(Which is why I call this a work-around: it's not fully integrated with PMWiki yet.)
- The actual login pages are written in PHP but need to be housed in the same Domain, but NOT in the PMWiki directory.
- User lists are maintained by creating a MySQL Table with all the available emails - the Whitelist, and then another Table for Registered users and Authorization Levels.
- The email functions are handled by PHPMailer which needs to be installed on the Domain with the PMWiki, or you can rewrite the code for your preferred email handler.
- All essential configuration settings are in a single setup.php file, all other files use variables and constants set there.
Once configured, you can add PHP code to a Group or a Page (using /local/GroupName.php or /local/GroupName.PageName.php) which allows, blocks or redirects any user based on their Authorization code.
Sample code and instructions are included in the MyDBLogin.zip file, in the /local/Verified.php file.
There are a number of steps, but nothing should be very complicated,
and there are lots of comments in the setup file to help.
The zip file includes a, pretty much, drop-in set of files to easily get a working model up and running.
Files are already in their default directories, if you have your wiki in
you could just unzip the file, edit the /mydblogin/setup.php file, and then copy everything directly to your domain root!
But you DO need to go to the /mydblogin folder and edit the setup.php file, using the extensive comments.
It contains the configuration settings for pmwiki, MySQL and PHPMailer, just fill in your specific names, paths and passwords.
All the other files work from the one setup and do not need editing to get a working version.
You can customize later, again, everything is heavily commented, but this will get you a fully working demo!
You might want to check if there is a newer version of includeSite than the one included,
but my version is edited to work better for responsive websites.
What you will need to get ready on your own:
A working PMWiki installation!
You will need to install includeSite - My version is included in the Zip file, to be copied to pmwiki/cookbook
Then add the following line into your config.php
A MYSQL database with two tables configured for MyDBLgin the Whitelist and Authorized users, need to be set up and accessible.
A file with SQL templates is included.
PHPMailer must be installed on the same server as your pmwiki site and an account available to use.
For MyDBLogin itself you will want:
A folder/directory in the same domain, outside of the PMWiki installation.
ideally you have something like:
Then within the PMWiki you add a Group/Page for the MyDBLogin
I happen to call mine:
This page has only one user text entry:
(:includeSite https://www.myexampledomain.org/mydblogin :)
Download the MyDBLogin.zip file above and unzip to somewhere you can edit the necessary files.
- All files in the mydblogin directory need to be copied to your server in the mydblogin directory.
- the included files in the pmwiki directory are sample code, but if you copy them to your pmwiki installation the demo should work nicely.
- The only file needing any modification is the setup.php file, and the pages in your PMWiki you use to direct/redirect or restrict access.
Once you have all the prerequisites (mySQL, Mailer, and Includesite) installed and working you will need to edit the setup.php file to add your specific environment variables.
- You will need to set up your MYSQL tables, the included MYSQL.txt file has code to create your tables.
* You will need to load the database tbl_whitelist with the available emails. (I use the MYSQL-for-Excel add-on so
- I just maintain my user list in Excel, and upload/update from there) It is my intention to build a set
of maintenance pages to work from within PMWiki in the future but I'm not there yet.
- the MyDBLogin files loaded onto the server,
- PHPMailer installed and tested on the same server,
- includeSite installed and tested,
- the setup.php file edited to match your MYSQL server and PHPMailer account information.
- The MYDBLogin PMWiki page with the includeSite reference.
- A "NoAuth" page in your wiki, to tell users when their login credentials are insufficient
You are now ready to password protect whole Group sections, or single pages!
See the Verified.php file in the pmwiki/local folder, you can simply copy and rename this to match any Group.php or
Group.SinglePage.php and copy that file to your servers pmwiki/local directory. After that only users logged-in
with MyDBLogin will be able to access those pages.
See PMWiki's page on Group configurations for more details.
That's all you need to get started, now you can modify and customize as you please!
Primary configuration - for MYSQL, PHPMailer, and your local installation, are handled in the setup.php file, which is heavily commented.
Otherwise, you may choose to edit the css files, the wording on the pages and emails.
- The actual page restrictions are handled with the GroupName.php files and a sample file is included: MyDBLogin.zip -- pmwiki/local/Verified.php
See the ~HowTo.txt file in the MYDBLogin.zip file for more detailed instructions.
MyDBLogin allows you to lock whole Groups or Pages from access by anyone who is not Registered in your whitelist and Logged in.
By adding a GroupName.php or GroupName.PageName.php file to your pmwiki/local folder, you can set specific rules for who has access to your Group/Page.
see the pmwiki page on Group Configuration to better understand this: GroupCustomizations
The MyDBLogin.zipΔ includes a sample verified.php, to go in your pmwiki/local directory.
Then any page in the 'Verified' Group will require an Authorized user.
(Although, you could use a page specific /local file to over-ride this if you want.)
E.g. a wiki page named:
[[Verified.Directory]], since it is in the Verified Group,
would send anyone not logged in with MyDBLogin, to the MyDBLogin page to require them to log in.
The protected page is never loaded until password validation is correct.
To do / some day / maybe
- Add Sample DB maintenance pages.
- Make the select user list optional.
- Use this same idea to house other PHP code for DB maintenance (CRUD) accessible from within the Wiki.
- Make the whitelist (limited list of users) optional, allowing anyone to self-register.
- Add code to limit or link access using other outside tools.
If you have future plans or wishes for this recipe.
Change log / Release notes
Expect to see this page finished by 2019-20-31
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".