MediaWiki is the powerful software on which Wikipedia and many other sites are built. It does not, however, come with the option to password protect pages from being viewed. (It can password protect pages from being edited.)
If you need to setup a private, members-only wiki for internal use, here is how you can do it with MediaWiki software and the Apache server extension mod_auth_mysql:
1. Install MediaWiki as usual. Create a user account for yourself.
2. Add the following line to your LocalSettings.php file, located in the root of your MediaWiki installation. This will cause MediaWiki to use a simple MD5 hash for user passwords in the database, instead of the more complicated “salted hash hash” that it normally uses.
$wgPasswordSalt = false;
3. Activate mod_auth_mysql in Apache. This is usually done with a LoadModule line in your Apache configuration file (httpd.conf), provided the module is available. (If not, you may need to compile or download the module.)
LoadModule mysql_auth_module libexec/apache2/mod_auth_mysql.so
4. Create a new MySQL user that has SELECT access to the “user_name” and “user_password” fields in the “user” table of your MediaWiki installation. Apache will use this MySQL user for connecting to the MediaWiki database.
5. Configure mod_auth_mysql to use the MediaWiki user table for authentication by placing the follow directives in your Apache configuration file:
AuthName "This wiki is password protected (make sure the first letter of the username is Uppercase)"
AuthType Basic
require valid-user
AuthMySQLEnable On
AuthMySQLHost localhost
AuthMySQLUser unprivilegeduser
AuthMySQLPassword thesecretpassword
AuthMySQLDB mediawikidatabase
AuthMySQLUserTable user
AuthMySQLNameField user_name
AuthMySQLPasswordField user_password
AuthMySQLPwEncryption md5
AuthMySQLAuthoritative On
6. Restart Apache.
Your installation of MediaWiki should now be password-protected, but your username and password will let you in. This protects the entire wiki; no one will even know that MediaWiki is present until they login. To give other people access, you can either create user accounts for them, or you can create a guest account that they can use until they sign themselves up.
P.S. Thanks to Gary Thornock for helping me with the details of installing mod_auth_mysql on FreeBSD.
UPDATE (2008-09-11):
The latest version of MediaWiki (version 1.13) uses a new password format which is incompatible with mod_auth_mysql. It prepends “:A:” to each MD5 hash. Here is a workaround:
1. Create a MySQL view that mirrors the username and password, minus the prefix:
CREATE VIEW user_view AS SELECT user_id, user_name, substring_index(user_password, ':', -1) AS user_password FROM user;
2. Configure mod_auth_mysql to use user_view instead of user as the lookup table.
38 replies on “Password protecting MediaWiki with mod_auth_mysql”
My just made extension that does the trick for mod_auth_mysql with md5 now in case there is no way to create a mysql view:
http://subfiles.net/mediawiki/mediawiki-extension-mod_auth_mysql-v0-1.zip
(mediawiki-1.15.1)
feel free to delete all my comments and you can offer the link on top (or offer the zip as well, it’s released under AGPL).
With my mediawiki-1.15.1 and $wgPasswordSalt = false; mediawiki will use only md5() to create the hash but it will prefix the value in the database with :A:.
Right now I have not found a solution to circumvent that with built in methods.
There is a mediawii hook called UserCryptPassword ( &$password, &$salt, &$wgPasswordSalt, &$hash ) that can overwrite the hash creation. this could be used to create a mediawiki php extension (will try that now) incorporating that routine. maybe this already exists as well.
this is identified cause why mysql auth didn’t work any longer mediawiki in my case.
Please ignore my last comment, I checked the values in the DB against md5($pass) and it is correct, a simple md5 hash is in there.
Need to make more checks.
Did not work for me. I have problems to get it to work with mediawiki-1.15.1. I assume that the passwords stored inside the DB are not stored in a format that can be handled by the mysql auth module any longer. Authorization just does not work. Maybe a change in the data definition and hashing?
user_name varchar(255) – utf8_bin –
user_password tinyblob – – BINARY
I need to check wether or not blobs are suppored. I even created a new user AFTER changing the $wgPasswordSalt = false; directive to false. Logging in with the new user into mediawiki does work. Over the httpd authentication the new user can not log in (as well as the old user can’t).
@Rob Velseboer
Worked like a charm.
As Paul mentioned, the quotes in $wgWhitelistRead needed changing. Other than that, there was no needto install DB Modules and yet I was able to password protect the wiki for authorised users only. It also prevented anonymous users from creating new accounts.
Kind regards,
Manoj
@Richard I just wrote some code and it seems to work.
I didn’t need to create a new cookie, because the UserID cookie is only to be found, when the user is logged in, so I copied some code from include/User.php method loadFromSession. Now you still could log out, but you never need to login, because with each request you’re automatically logged in with your HTTP Auth login data if the UserID cookie isn’t present.
I’m just tidying up my code and may send you the extension later today.
@Götz: Ah, I see what you mean, and it seems like you have a good idea here. I hope it works. If you create a plugin for it, let me know.
Hi Richard,
thank you for yozur reply. That’s exactly what I’m trying to do. However MediaWiki seems to provide no user/session data when the UserLoadFromSession hook is called. I thought about just creating an own additional cookie using the UserLoginComplete hook and check this cookie to avoid the redirection loop.
Kind regards,
Götz
@Götz: I haven’t seen anyone do this yet, but I’d be interested in it too. I assume you’d need some sort of MediaWiki plugin that looks for the presence of $_SERVER[‘PHP_AUTH_USER’] and $_SERVER[‘PHP_AUTH_PW’] and then bypasses the login form with those credentials.
Hello Richard,
thanks for this great tutorial. After I struggled a bit with some configuration settings (different versions of the module and different names of directives, …) I managed to set this up successfully.
But I’m still working on a single sign on. I tried forwarding the login data (I run PHP as module) to the MediaWiki login form but either I get a redirection loop to the main page or when I turn off the redirection I get an error mesage that $wgTitle is empty.
Did anyone who comes by here manage to make MediaWiki use the HTTP Auth data to log in users correctly (as this is no “external authentiocation” the modules which I found didn’t meet my needs).
Kind regards,
Götz
@Rob Velseboer
Your instructions for modifying LocalSettings.php to hide pages, require login, etc were PERFECT. I didn’t have to go modifying my db, apache which made it so much easier.
One thing to note is that the line that contains your $wgWhitelistRead in your example has “smart quotes” and if you copy/paste it into your LocalSettings.php, PHP will die. Just change them to normal quotes and you’ll be fine.
Thanks for this posting. I set this up a few years back using MediaWiki version 1.7 at the time. I had a need for the same setup at a new job and ran into a road block which looked like :A: before each password. This post saved me time fiddling for a work around. Works great on Debian Etch with latest MediaWiki release.
Rob – thanks for the advice! I don’t have access to the apache configuration on my server, so it was much simpler to just hide the content from anonymous users. Works great.
Quote-
You’ll need to uncompress the .tar.gz file with tar -xzf. If it produces an .so file then you can place it with the others .so files and then include it in your Apache configuration file. If it produces source, then you’ll need to compile it with “sudo make install”.
I’m a giant among midgets at my job, where I’ve been setting up an intranet (WinXP, Apache 2+PHP, MediaWiki, MySql, FreeBSD).
Unfortunately, I’ve been having trouble extending Apache by installing modules like mod_auth_mysql, mod_dav, etc. I don’t know how to uncompress a tar.gz with -xsf under windows. Is there an application that does this? I don’t know how to get/make .so plug in files.
Just a note, using the “Basic” type of authentication transmits all passwords as plaintext and makes this method of securing easily compromised using packet sniffing. I suggest that if you want to use this method that you secure your wiki using SSL so that all info from login and the wiki is encrypted and cannot be sniffed.
Nathan: Thank you for your comment. I had just upgraded to Apache 2.2 (also running FreeBSD 6.2, MediaWiki 1.11, and mod_auth_mysql_another-3.0.0) so your insight was just what I needed.
I was getting the same ” Could not open password file: (null)” error from Richard’s example. I tried the format that Tecteun suggests, but that didn’t work either. I did some googling and found this – https://secure-support.novell.com/KanisaPlatform/Publishing/652/3810088_f.SAL_Public.html
Which says that it’s an issue of basic auth, and suggests adding the line “AuthBasicAuthoritative Off” so I added that to Richard’s example and that made things go. I hope that is of benefit to others.
It may benefit others to mention the version used. FreeBSD 6.3, Mediawiki 1.11.1, apache-2.2.8, mod_auth_mysql_another-3.0.0_2 (from the ports collection).
This configuration documentation for mod_auth_mysql might also help people : http://modauthmysql.sourceforge.net/CONFIGURE
If you still get “Could not open password file” after taking the above step, add this directive as well:
AuthUserFile /dev/null
Actually, you can protect Mediawiki against both reading and writing by anonymous users. Put these lines in your LocalSettings.php file to do so:
$wgGroupPermissions[‘*’][‘edit’] = false;
$wgGroupPermissions[‘*’][‘read’] = false;
Now, anonymous users cannot read any pages, except for the ones you explicitly whitelist, like this:
$wgWhitelistRead = array( “Special:Userlogin”, “-“, “MediaWiki:Monobook.css”, “Main_Page” );
That line is probably already in your LocalSettings.php, just add pages you want anonymous users to see.
If you don’t even want them to see your wiki front page, remove “Main_Page” from this list.
Visitors will now be asked to log in immediately, even before they get to see your front page.
Unfortunately, by default Mediawiki lets users create their own accounts and this would mean that anonymous visitors can just create an account and have all the privileges you didn’t want them to have.
Protect your wiki against account creation by adding this line to LocalSettings.php:
$wgGroupPermissions[‘*’][‘createaccount’] = false;
Be aware that now legitimate new users cannot create their own accounts either, (but that problem also existed with the mod_auth_mysql approach).
There is a way for wiki admin users to create new accounts though:
* Go to the Special:Userlogin page (after loging in as an admin)
* Click “Create an account”
* Fill in the form, uncheck the box “Remember my login on this computer”
* Click “by e-mail”
The new user gets an e-mail with a generated password (I found out the password I typed in the form was discarded)
After logging in for the first time, the new user is asked to choose a new password.
Hope this is useful for people who don’t have access to the Apache configuration on their site, and also for people who are annoyed by having to log in twice.
this was the specific error i got:
[Fri Apr 06 12:33:18 2007] [error] [client 192.168.1.52]
(9)Bad file descriptor: Could not open password file: (null)
(sorry, this should be in my previous post, if there was an edit option)
I got a lot of nullpointer errors in my /var/log/httpd/error_log, i fixed it by changing the order of Auth parameters :
AuthName “This wiki is password protected (make sure the first letter \
of the username is Uppercase)”
AuthGroupFile /dev/null
AuthUserFile /dev/null
AuthMySQLEnable On
AuthMySQLHost localhost
AuthMySQLUser wikiuser
AuthMySQLPassword wikipassword
AuthMySQLDB wunderwikidb
AuthMySQLUserTable user
#AuthMySQLUserCondition “users.status = 1”
AuthMySQLNameField user_name
AuthMySQLPasswordField user_password
AuthMySQLNoPasswd Off
AuthMySQLPwEncryption md5
AuthMySQLAuthoritative On
require valid-user
Now its working 🙂
hope someone can use this info
Just wanted to say that this’s very useful 🙂 I’ve used the mysql module to password protect other pages. Just wanted to add something to keep in mind.
Since mod_auth_mysql is being used with apache in basic authentication mode, as with any other basic apache auth scheme, it will request your username/password every time you goto the page. Most modern browsers cache username/password for that reason.
So keep in mind that if you use this method (as opposed to php sessions or so), if the page is not closed (and/or cache is not purged, depending on browser) – the browser will let anybody else access that page as long as the username/password are in the cache.
So if you are using your wiki from a public access computer, keep that in mind. 🙂
I’m currently building a mission critical system and had to work around this problem.
@Robert
Thanks for stopping by! I’m glad you found the post. Gary Thornock was the other Utahn that helped craft this solution.
Richard…
Very cool. First thing I looked for when trying to password protect a wiki at home. Very well done. And to think you are another Utah County-ite, mac lover and fellow member.
-Robert
@Dawa
You’ll need to uncompress the .tar.gz file with tar -xzf. If it produces an .so file then you can place it with the others .so files and then include it in your Apache configuration file. If it produces source, then you’ll need to compile it with “sudo make install”.
though i have installed mediawiki on my webserver in my LAN. Since i’m new to all the apahce, mysql and wiki. So could you please tell me how do i manually install apache module called “mod_auth_mysql-3.00.tar.gz” that i have downloaded for installing “LoadModule mysql_auth_module libexec/apache2/mod_auth_mysql.so”
thanks a lot in advance.
Hi leo, you are correct about having to login twice. In theory you could get MediaWiki to recognize that you’re already logged in to Apache, but I haven’t ventured there!
Thanks for this article! I have just installed the wiki with mod_auth_sql as described above. But I have just one more question. Is it correct that I have to login twice? After the apache login I am an anonymous user in the context of the wiki. So I have to login again that the wiki knows who I am? Is that right?
Greg, I don’t know of any way to protect only some of the pages with this method, but you could definitely install multiple instances of MediaWiki and protect one but not another.
This is VERY useful thank you!
Any ideas on how to password protect only SOME wikimedia pages and not the ENTIRE thing?
Alternatively can you run multiple wikimedia instances on one system and password protect only one of them?
scragz: Thanks for your comments. I’m glad to know what happened when you had existing customers.
Also, if you already have users setup, you need to change their passwords after you do the “$wgPasswordSalt = false;” bit. I only had two users who I knew the passwords for, so I just retyped them into phpMyAdmin and put the MD5 function on.
My install on CentOS required the following changes:
AuthName "This wiki is password protected (make sure the first letter of the username is Uppercase)"AuthType Basic
require valid-user
##AuthMySQLEnable On # this directive didn't exist
AuthMySQLHost localhost
AuthMySQLUser imotion_wiki
AuthMySQLPassword 400z13
AuthMySQLDB imotion_wiki
AuthMySQLUserTable user
AuthMySQLNameField user_name
AuthMySQLPasswordField user_password
##AuthMySQLPwEncryption md5
AuthMySQLMD5Passwords On # had to add this instead of the above
AuthMySQLAuthoritative On