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.
Pingback: Gary Thornock's Weblog » MediaWiki and mod_auth_mysql
Pingback: The Lone Sysadmin » links for 2006-06-01
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
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?
thanks a lot in advance.
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”.
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
Thanks for stopping by! I’m glad you found the post. Gary Thornock was the other Utahn that helped craft this solution.
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.
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
[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)
Pingback: NetMusician Labs » Blog Archive » Password protect your Mediawiki wikis
$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.
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
Pingback: nformation » Securing Mediawiki
Pingback: » What goes around, comes around Richard K Miller
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.
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 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
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
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.
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
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).
Need to make more checks.
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.
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).